Re: KASAN vs realloc

["Maciej Żenczykowski" <maze@google.com>]

On Fri, Feb 6, 2026 at 12:14 PM Maciej Wieczor-Retman
<m.wieczorretman@pm.me> wrote:
>
> 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.

Cool, thanks for checking.

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

--
Maciej Żenczykowski, Kernel Networking Developer @ Google