Details
- Reviewers
pcc eugenis - Commits
- rGbae9527c2044: [hwasan] Add report for wild frees.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
From the user PoV, wild-free is not different from invalid-free, and the extra info in the invalid-free reports helps. It's useful to know that the bad free-ed pointer is actually a stack pointer, or maybe a valid heap pointer + 4 bytes, or something like that.
If the concern is with the shadow access in ReportInvalidFree overflowing, that can be checked.
Thanks! Added test and fixed division by null triggered by this.
compiler-rt/lib/hwasan/hwasan_checks.h | ||
---|---|---|
70 ↗ | (On Diff #365726) | Ah yes of course, with sz > 0 you are correct. This was to make sure we don't try to access memory that's not mapped (so it should not have shadow memory). |
compiler-rt/lib/hwasan/hwasan_allocator.cpp | ||
---|---|---|
207 | This is now an mmap -> copy of secondary metadata -> O(n) walk of the secondary on each secondary-deallocation. For performance reasons, I think we should only do this for the primary (guard with allocator.FromPrimary(..)). Secondary invalid-free is possible, but requires some changes to the secondary allocator itself. |
This is now an mmap -> copy of secondary metadata -> O(n) walk of the secondary on each secondary-deallocation.
For performance reasons, I think we should only do this for the primary (guard with allocator.FromPrimary(..)). Secondary invalid-free is possible, but requires some changes to the secondary allocator itself.