Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator

[Vlastimil Babka]

On 9/4/19 4:24 PM, Walter Wu wrote:
> On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote:
>> On 9/4/19 4:06 PM, Walter Wu wrote:
>>
>> The THP fix is not required for the rest of the series, it was even merged to
>> mainline separately.
>>
>>> And It looks like something is different, because we only need last
>>> stack of page, so it can decrease memory overhead.
>>
>> That would save you depot_stack_handle_t (which is u32) per page. I guess that's
>> nothing compared to KASAN overhead?
>>
> If we can use less memory, we can achieve what we want. Why not?

In my experience to solve some UAFs, it's important to know not only the
freeing stack, but also the allocating stack. Do they make sense together,
or not? In some cases, even longer history of alloc/free would be nice :)

Also by simply recording the free stack in the existing depot handle,
you might confuse existing page_owner file consumers, who won't know
that this is a freeing stack.

All that just doesn't seem to justify saving an u32 per page.

> Thanks.
> Walter
> 
> 
>