Bug 1482121
| Summary: | python audit crash due to dereferencing NULL auparse_state_t le field. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Paulo Andrade <pandrade> |
| Component: | audit | Assignee: | Steve Grubb <sgrubb> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.3 | CC: | mthacker, omoris, pandrade |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | audit-2.7.8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 12:18:47 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1476406 | ||
|
Description
Paulo Andrade
2017-08-16 13:49:00 UTC
This kind of looks like its using the ausearch functions of auparse. Is there any possibility of finding out if it is setting up a search and what it's searching for? By any chance do we have a reproducer? (In reply to Steve Grubb from comment #5) > By any chance do we have a reproducer? I am afraid there is still not a reproducer. User was instructed to attempt to save the input that caused the crash, and when it happens, also save the script that triggered it. But still waiting for it. I can provide you a coredump with the backtrace: Program terminated with signal 11, Segmentation fault. #0 0x00007f1a4d98f774 in auparse_get_type_name (au=0x17b6910) at auparse.c:1654 1654 rnode *r = aup_list_get_cur(au->le); (gdb) p *au $1 = {source = AUSOURCE_FILE, ... and the list of dependencies to load the coredump, as you might find something else in the backtrace. Without the script I can't tell much. For example, if it failed to open the file does it continue? Does it call first_record and if so does it check the return code? au->le is only ever NULL when no event is available. That said, I did find that auparse_get_type_name in the python bindings itself did not check if it got NULL from the C function. It now sets an error code rather than try to build a value. So, if the crash is in the bindings itself, then maybe upstream commit bc9051adb81645846a8b4ab25280d09082b2e12e may solve the issue. Btw, the attached script, audit_report-1.py, appears to be OK. Not sure how similar that is to the one that is crashing. Actually, it just crashes on an empty file: $ echo -n '' > /tmp/ausearch.log $ python audit_report-1.py Segmentation fault (core dumped) This is why I suggested not calling aup.first_record() and then a "while True:" loop. But my suggestion apparently caused the script to miss the first entry. OK, you are right. Without changing everything the program could do something like this:
if not aup.first_record():
sys.exit(1)
So, the program is accessing an empty file and return codes are not being checked. You definitely can crash auparse through almost any function call when there is no selected event.
I checked in 2 patches that should fix this. I now get an exception when using the API with no event selected. Built audit-2.7.8 to address this issue. 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, 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-2018:0760 |