Bug 198425
Summary: | KASAN: don't print free stack when object is not free | ||
---|---|---|---|
Product: | Memory Management | Reporter: | Dmitry Vyukov (dvyukov) |
Component: | Sanitizers | Assignee: | Dmitry Vyukov (dvyukov) |
Status: | RESOLVED CODE_FIX | ||
Severity: | enhancement | CC: | aryabinin, willemb |
Priority: | P2 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | ALL | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Dmitry Vyukov
2018-01-10 09:11:19 UTC
See this: https://groups.google.com/g/syzkaller-bugs/c/TVGAFDeUKJo/m/-3-Be05sAQAJ how the irrelevant free stack confused Daniel, and he wanted to write off report as bogus and corrupted. Keeping information in one place:
Andrey Ryabinin replied:
> Because we have that information (free stack) and it usually better to
> provide
> all the information we have rather than hide it. You never known what
> information
> might be needed to fix the bug.
> Free memory might be reused and what we report as OOB might be an UAF and
> free stack
> could be useful in such case.
Willem just stared debugging an OOB as UAF being confused by the Free stack. Willem, is my interpretation correct? Or you think that OOB is really an UAF? Note: the heap block (identified by the Allocated stack) is not freed at all at the time of the report. I think at least we need to replace "Freed" with some meaningful explanation of what really this stack represents and the state of the object. Suggestions for a concise one-line wording are welcome. Indeed, I also mistook the output of "Allocated by" and "Freed by" as implying that I was looking at a use-after-free. Maybe "Last Freed by", or an explicit note that the free event may have preceded the allocate event? Another user confused by this "free stack for a not freed object": https://groups.google.com/d/msg/syzkaller-bugs/hCj_dXTfd94/gFpw8mLFAwAJ This was resolved as part of changes for Bug 198437. We now store free meta in the object so we don't have/can't print free stack for active objects. |