A heap or global buffer that is far away from the faulting address is
unlikely to be the cause, especially if there is a potential
use-after-free as well, so we want to show it after the other
causes.
Details
- Reviewers
eugenis pcc - Commits
- rGb458bb8c04cd: [hwasan] Display causes in order of probability.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@pcc @hctim
I'd like to have a test that a far overflow is not printed where there is a valid use after free.
You can do it by
- allocating in a loop until you get too allocations that are nearby but not adjacent
- faking the tags so they match (__hwasan_tag_memory can do that)
- deallocating one and touching it
hwasan does not record the original allocation tag anywhere (but it records "free" in the history buffer)
compiler-rt/lib/hwasan/hwasan_report.cpp | ||
---|---|---|
318 | Make it "Cause:" to match the MTE output: Add an explanation about multiple possible causes somewhere. It seems hard to count them before printing, so I'm ok with the note going to the end of the report. | |
420 | The only way to "describe" a stack location is through the history buffer. ShowCandidate should iterate over it looking for a matching tag and address (but unlike use-after-return, the address would be the suspected overflow address, not the fault address, and the tag would match the current memory tag). This becomes complicated in the offline symbolization case (see the hwasan_symbolize script). Unsymbolized online reporting would need to print tag and address of the suspected original allocation that can be matched against offline symbolized history. This is out of scope of this change. | |
474 | I suggest we do not print "far" overflow candidates if there is any other alternative at all (i.e. num_descriptions > 0). |
LGTM with the test changes
compiler-rt/test/hwasan/TestCases/use-after-free-and-overflow.c | ||
---|---|---|
23 | distance is in bytes, you probably want something more than 1. | |
40 | break if other != nullptr? | |
46 | This can flake if any of the adjacent allocations have a tag of 3. Maybe iterate over possible tag values until __hwasan_test_shadow both on the left and on the right returns an error? |
Improve test.
compiler-rt/test/hwasan/TestCases/use-after-free-and-overflow.c | ||
---|---|---|
46 | I think it's easier to just tag the two surrounding bytes to prevent the flake. |
LGTM
compiler-rt/test/hwasan/TestCases/use-after-free-and-overflow.c | ||
---|---|---|
20 | nit: single statement blocks do not use {} in LLVM |
Make it "Cause:" to match the MTE output:
https://cs.android.com/android/platform/superproject/+/master:system/core/debuggerd/libdebuggerd/tombstone_proto_to_text.cpp;l=263;drc=78f0670ddadb98c270cc0a0115bb4da4e5d80a95
Add an explanation about multiple possible causes somewhere. It seems hard to count them before printing, so I'm ok with the note going to the end of the report.