[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANP3RGeHnhufYyc0P2OiKJbXdZjPW41TP=JS6nYk9xGRU8UuKQ@mail.gmail.com>
Date: Fri, 6 Feb 2026 11:07:12 -0800
From: Maciej Żenczykowski <maze@...gle.com>
To: Maciej Wieczor-Retman <m.wieczorretman@...me>, Andrey Ryabinin <ryabinin.a.a@...il.com>
Cc: 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
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.
Powered by blists - more mailing lists