linux-kernel - Re: KASAN vs realloc

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]

Message-ID: <aYZJ2Ohug6b9Vth0@wieczorr-mobl1.localdomain>
Date: Fri, 06 Feb 2026 20:14:25 +0000
From: Maciej Wieczor-Retman <m.wieczorretman@...me>
To: Maciej Żenczykowski <maze@...gle.com>
Cc: Andrey Ryabinin <ryabinin.a.a@...il.com>, Kees Cook <kees@...nel.org>, joonki.min@...sung-slsi.corp-partner.google.com, Andrew Morton <akpm@...gle.com>, Alexander Potapenko <glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>, Marco Elver <elver@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Uladzislau Rezki <urezki@...il.com>, Danilo Krummrich <dakr@...nel.org>, jiayuan.chen@...ux.dev, syzbot+997752115a851cb0cf36@...kaller.appspotmail.com, Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>, kasan-dev@...glegroups.com, Kernel hackers <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: KASAN vs realloc

>From what I see kasan_poison_last_granule() is called through:

__kasan_vrealloc()
--> __kasan_unpoison_vmalloc()
----> kasan_unpoison()
------> kasan_poison_last_granule()

and the arguments are "addr + old_size" and "new_size - old_size" so it looks
okay I think.

On 2026-02-06 at 11:07:12 -0800, Maciej Żenczykowski wrote:
>While looking at:
>  https://android-review.git.corp.google.com/c/kernel/common/+/3939998
>  UPSTREAM: mm/kasan: fix KASAN poisoning in vrealloc()
>
>I noticed a lack of symmetry - I'm not sure if it's a problem or not...
>but I'd have expected kasan_poison_last_granule() to be called
>regardless of whether the size shrunk or increased.
>
>It is of course possible this is handled automatically by
>__kasan_unpoison_vmalloc() - I haven't traced that deep,
>in general these functions seem to have a terrible api surface full of
>razors... with hidden assumptions about what is and is not granule
>aligned.

-- 
Kind regards
Maciej Wieczór-Retman