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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 5 Sep 2019 10:03:28 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Walter Wu <walter-zh.wu@...iatek.com>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Arnd Bergmann <arnd@...db.de>, kasan-dev@...glegroups.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, wsd_upstream@...iatek.com
Subject: Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator

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
> 
> 
>