Bug 1861301

This bug was initially created as a copy of Bug #1861300

I am copying this bug because: 

From plain looking at the code, the issue is still present on RHEL8.2.
The source file is now named "rpmverifyfile_probe.c".

Description of problem:

A huge memory leak is present in probe_rpmverifyfile, causing various issues on the system when executing oscap, typically OOMKiller starts killing processes and services.

On a small system with 450 RPMs, the memory consumed grows up to 900 MB!

    ==1668== 901,115,904 bytes in 219,999 blocks are definitely lost in loss
    record 77 of 77
    ==1668==    at 0x4C29F73: malloc (vg_replace_malloc.c:309)
    ==1668==    by 0x749B93D: realpath@@GLIBC_2.3 (canonicalize.c:78)
    ==1668==    by 0x10EC5D: UnknownInlinedFun (stdlib.h:48)
    ==1668==    by 0x10EC5D: rpmverify_collect (rpmverifyfile.c:249)
    ==1668==    by 0x10EC5D: probe_main (rpmverifyfile.c:546)
    ==1668==    by 0x110C4F: probe_worker (worker.c:954)
    ==1668==    by 0x11074B: probe_worker_runfn (worker.c:56)
    ==1668==    by 0x7243EA4: start_thread (pthread_create.c:307)
    ==1668==    by 0x75568DC: clone (clone.S:111)
    
    ==1668== LEAK SUMMARY:
    ==1668==    definitely lost: 901,150,675 bytes in 224,438 blocks


Version-Release number of selected component (if applicable):

openscap-1.2.17-9.el7_8 and later


How reproducible:

Always


Steps to Reproduce:
1. Start probe_rpmverifyfile under Valgrind

  # /usr/bin/valgrind --tool=memcheck --leak-check=yes /usr/libexec/openscap/probe_rpmverifyfile

2. Send the various orders on stdin one at a time, wait for result

First: (fast)
(#d8:seap.msg#d3::id#d0((#d20:rpmverifyfile_object#d3::id#d47:oval:ssg-object_files_fail_user_ownership:obj:1#d13::oval_version#d4:5.11)((#d4:name#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d5:epoch#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d7:version#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d7:release#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d4:arch#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d8:filepath#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d6:filter#d7::action#d2)#d46:oval:ssg-state_files_fail_user_ownership:ste:1)((#d9:behaviors#d6::nomd5#d4:true#d13::noghostfiles#d4:true))))

Second: (slow)
(#d8:seap.cmd#d3::id#d0#d9::reply_id#d0#d6::class#d3:usr#d5::type#d5:async#d1(((#d19:rpmverifyfile_state#d3::id#d46:oval:ssg-state_files_fail_user_ownership:ste:1#d9::operator#d1)((#d17:ownership_differs#d10::operation#d5#d10::var_check#d1#d13::entity_check#d1#d16::check_existence#d3)#d4:fail))))

Third: (fast)
(#d8:seap.msg#d3::id#d1((#d20:rpmverifyfile_object#d3::id#d48:oval:ssg-object_files_fail_group_ownership:obj:1#d13::oval_version#d4:5.11)((#d4:name#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d5:epoch#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d7:version#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d7:release#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d4:arch#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d8:filepath#d10::operation#d11#d10::var_check#d1)#d2:.*)((#d6:filter#d7::action#d2)#d47:oval:ssg-state_files_fail_group_ownership:ste:1)((#d9:behaviors#d6::nomd5#d4:true#d13::noghostfiles#d4:true))))

Fourth: (slow)
(#d8:seap.cmd#d3::id#d1#d9::reply_id#d1#d6::class#d3:usr#d5::type#d5:async#d1(((#d19:rpmverifyfile_state#d3::id#d47:oval:ssg-state_files_fail_group_ownership:ste:1#d9::operator#d1)((#d13:group_differs#d10::operation#d5#d10::var_check#d1#d13::entity_check#d1#d16::check_existence#d3)#d4:fail))))


Actual results:

High memory consumption

Expected results:

Small memory consumption (~200MB)


Additional info:

This is a critical issue, system can get down due to this.