Bug 1861300
| Summary: | Huge memory leak in probe_rpmverifyfile [rhel-7.9.z] | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | openscap | Assignee: | Jan Černý <jcerny> |
| Status: | CLOSED ERRATA | QA Contact: | Matus Marhefka <mmarhefk> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 7.8 | CC: | cbesson, ekolesni, jcerny, jreznik, kwalker, mhaicman, reg, sadas |
| Target Milestone: | rc | Keywords: | AutoVerified, Regression, ZStream |
| Target Release: | --- | Flags: | lcervako:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-10 13:03:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The bug is reproducible also with current upstream maint-1.3 branch as of HEAD 802eb801dd083a67bd64d4f9c711ba1426e626cb. It seems to be triggered by any rule that uses rpmverifyfile probe, eg. xccdf_org.ssgproject.content_rule_rpm_verify_permissions, xccdf_org.ssgproject.content_rule_rpm_verify_ownership. For example, on Fedora 32: oscap xccdf eval --profile standard --rule xccdf_org.ssgproject.content_rule_rpm_verify_permissions /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml Valgrind reports the same leak: ==400443== ==400443== 352,256 bytes in 86 blocks are possibly lost in loss record 352 of 353 ==400443== at 0x483A809: malloc (vg_replace_malloc.c:307) ==400443== by 0x51F23A6: realpath@@GLIBC_2.3 (in /usr/lib64/libc-2.31.so) ==400443== by 0x489F8EA: oscap_realpath (util.c:251) ==400443== by 0x495E766: rpmverify_collect (rpmverifyfile_probe.c:248) ==400443== by 0x495F4D8: rpmverifyfile_probe_main (rpmverifyfile_probe.c:543) ==400443== by 0x493560F: probe_worker (worker.c:1090) ==400443== by 0x4932F87: probe_worker_runfn (worker.c:81) ==400443== by 0x4CDA431: start_thread (in /usr/lib64/libpthread-2.31.so) ==400443== by 0x52A99D2: clone (in /usr/lib64/libc-2.31.so) ==400443== ==400443== 2,359,775,232 bytes in 576,117 blocks are definitely lost in loss record 353 of 353 ==400443== at 0x483A809: malloc (vg_replace_malloc.c:307) ==400443== by 0x51F23A6: realpath@@GLIBC_2.3 (in /usr/lib64/libc-2.31.so) ==400443== by 0x489F8EA: oscap_realpath (util.c:251) ==400443== by 0x495E766: rpmverify_collect (rpmverifyfile_probe.c:248) ==400443== by 0x495F4D8: rpmverifyfile_probe_main (rpmverifyfile_probe.c:543) ==400443== by 0x493560F: probe_worker (worker.c:1090) ==400443== by 0x4932F87: probe_worker_runfn (worker.c:81) ==400443== by 0x4CDA431: start_thread (in /usr/lib64/libpthread-2.31.so) ==400443== by 0x52A99D2: clone (in /usr/lib64/libc-2.31.so) For posterity - as the rpmverifyfile probe is used in very limited number of SCAP rules, the workaround for now is to use tailoring, and remove those rules: * file_permissions_unauthorized_sgid * rpm_verify_hashes * rpm_verify_permissions * rpm_verify_ownership This will prevent the crashes. With that, I am slightly reducing the severity rating of the BZ. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openscap bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:5017 |
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.