linux-kernel - Re: [PATCH] mm-kasan-fix-kasan-poisoning-in-vrealloc-fix

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAPAsAGxiPhL7evokSWWXveVdZjU+8kUSjCA1PnEA9WGP2hiFxg@mail.gmail.com>
Date: Wed, 21 Jan 2026 17:01:38 +0100
From: Andrey Ryabinin <ryabinin.a.a@...il.com>
To: Andrey Konovalov <andreyknvl@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Maciej Żenczykowski <maze@...gle.com>, 
	Maciej Wieczor-Retman <m.wieczorretman@...me>, Alexander Potapenko <glider@...gle.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>, 
	kasan-dev@...glegroups.com, Uladzislau Rezki <urezki@...il.com>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [PATCH] mm-kasan-fix-kasan-poisoning-in-vrealloc-fix

On Tue, Jan 20, 2026 at 6:46 PM Andrey Konovalov <andreyknvl@...il.com> wrote:
>
> On Mon, Jan 19, 2026 at 3:46 PM Andrey Ryabinin <ryabinin.a.a@...il.com> 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@...il.com>
> > ---
> >  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.