Re: [PATCH] mm-kasan-fix-kasan-poisoning-in-vrealloc-fix
From: Andrey Ryabinin
Date: Wed Jan 21 2026 - 11:02:44 EST
On Tue, Jan 20, 2026 at 6:46 PM Andrey Konovalov <andreyknvl@xxxxxxxxx> wrote:
>
> On Mon, Jan 19, 2026 at 3:46 PM Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> wrote:
> >
> > Move kasan_enabled() check to header function to avoid function call
> > if kasan disabled via boot cmdline.
> >
> > Move __kasan_vrealloc() to common.c to fix CONFIG_KASAN_HW_TAGS=y
> >
> > Signed-off-by: Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx>
> > ---
> > include/linux/kasan.h | 10 +++++++++-
> > mm/kasan/common.c | 21 +++++++++++++++++++++
> > mm/kasan/shadow.c | 24 ------------------------
> > 3 files changed, 30 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index ff27712dd3c8..338a1921a50a 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -641,9 +641,17 @@ kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> > __kasan_unpoison_vmap_areas(vms, nr_vms, flags);
> > }
> >
> > -void kasan_vrealloc(const void *start, unsigned long old_size,
> > +void __kasan_vrealloc(const void *start, unsigned long old_size,
> > unsigned long new_size);
> >
> > +static __always_inline void kasan_vrealloc(const void *start,
> > + unsigned long old_size,
> > + unsigned long new_size)
> > +{
> > + if (kasan_enabled())
> > + __kasan_vrealloc(start, old_size, new_size);
> > +}
> > +
> > #else /* CONFIG_KASAN_VMALLOC */
> >
> > static inline void kasan_populate_early_vm_area_shadow(void *start,
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index ed489a14dddf..b7d05c2a6d93 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -606,4 +606,25 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> > __kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG);
> > }
> > }
> > +
> > +void __kasan_vrealloc(const void *addr, unsigned long old_size,
> > + unsigned long new_size)
> > +{
> > + if (new_size < old_size) {
> > + kasan_poison_last_granule(addr, new_size);
>
> I wonder if doing this without a is_vmalloc_or_module_addr() check
> could cause issues. I remember that removing
> is_vmalloc_or_module_addr() checks from other vmalloc hooks did cause
> problems, but I don't remember what kind.
>
vrealloc() operates only on vmalloc-backed allocations, so 'addr' is
always expected to be a vmalloc address here. Calling vrealloc() on a
non-vmalloc address would already be a misuse, independent of this change.