* + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch
@ 2025-11-28 18:55 Andrew Morton
2025-12-03 15:18 ` Andrey Konovalov
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2025-11-28 18:55 UTC (permalink / raw)
To: mm-commits, vincenzo.frascino, urezki, stable, ryabinin.a.a, kees,
glider, dvyukov, dakr, andreyknvl, jiayuan.chen, akpm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6926 bytes --]
The patch titled
Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Jiayuan Chen <jiayuan.chen@linux.dev>
Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
Date: Fri, 28 Nov 2025 19:15:14 +0800
Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two
issues:
1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when
unpoisoning the extended region. This flag is required to correctly
associate the allocation with KASAN's vmalloc tracking.
Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly
sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it.
vrealloc must behave consistently — especially when reusing existing
vmalloc regions — to ensure KASAN can track allocations correctly.
2. When vrealloc reuses an existing vmalloc region (without allocating new
pages), KASAN previously generated a new tag, which broke tag-based
memory access tracking. We now add a 'reuse_tag' parameter to
__kasan_unpoison_vmalloc() to preserve the original tag in such cases.
A new helper kasan_unpoison_vralloc() is introduced to handle this reuse
scenario, ensuring consistent tag behavior during reallocation.
Link: https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev
Link: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36 [1]
Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reported-by: syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/kasan.h | 21 +++++++++++++++++++--
mm/kasan/hw_tags.c | 4 ++--
mm/kasan/shadow.c | 6 ++++--
mm/vmalloc.c | 4 ++--
4 files changed, 27 insertions(+), 8 deletions(-)
--- a/include/linux/kasan.h~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/include/linux/kasan.h
@@ -596,13 +596,23 @@ static inline void kasan_release_vmalloc
#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
- kasan_vmalloc_flags_t flags);
+ kasan_vmalloc_flags_t flags, bool reuse_tag);
+
+static __always_inline void *kasan_unpoison_vrealloc(const void *start,
+ unsigned long size,
+ kasan_vmalloc_flags_t flags)
+{
+ if (kasan_enabled())
+ return __kasan_unpoison_vmalloc(start, size, flags, true);
+ return (void *)start;
+}
+
static __always_inline void *kasan_unpoison_vmalloc(const void *start,
unsigned long size,
kasan_vmalloc_flags_t flags)
{
if (kasan_enabled())
- return __kasan_unpoison_vmalloc(start, size, flags);
+ return __kasan_unpoison_vmalloc(start, size, flags, false);
return (void *)start;
}
@@ -629,6 +639,13 @@ static inline void kasan_release_vmalloc
unsigned long free_region_end,
unsigned long flags) { }
+static inline void *kasan_unpoison_vrealloc(const void *start,
+ unsigned long size,
+ kasan_vmalloc_flags_t flags)
+{
+ return (void *)start;
+}
+
static inline void *kasan_unpoison_vmalloc(const void *start,
unsigned long size,
kasan_vmalloc_flags_t flags)
--- a/mm/kasan/hw_tags.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/mm/kasan/hw_tags.c
@@ -317,7 +317,7 @@ static void init_vmalloc_pages(const voi
}
void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
- kasan_vmalloc_flags_t flags)
+ kasan_vmalloc_flags_t flags, bool reuse_tag)
{
u8 tag;
unsigned long redzone_start, redzone_size;
@@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi
return (void *)start;
}
- tag = kasan_random_tag();
+ tag = reuse_tag ? get_tag(start) : kasan_random_tag();
start = set_tag(start, tag);
/* Unpoison and initialize memory up to size. */
--- a/mm/kasan/shadow.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/mm/kasan/shadow.c
@@ -625,7 +625,7 @@ void kasan_release_vmalloc(unsigned long
}
void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
- kasan_vmalloc_flags_t flags)
+ kasan_vmalloc_flags_t flags, bool reuse_tag)
{
/*
* Software KASAN modes unpoison both VM_ALLOC and non-VM_ALLOC
@@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi
!(flags & KASAN_VMALLOC_PROT_NORMAL))
return (void *)start;
- start = set_tag(start, kasan_random_tag());
+ if (!reuse_tag)
+ start = set_tag(start, kasan_random_tag());
+
kasan_unpoison(start, size, false);
return (void *)start;
}
--- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/mm/vmalloc.c
@@ -4175,8 +4175,8 @@ void *vrealloc_node_align_noprof(const v
* We already have the bytes available in the allocation; use them.
*/
if (size <= alloced_size) {
- kasan_unpoison_vmalloc(p + old_size, size - old_size,
- KASAN_VMALLOC_PROT_NORMAL);
+ kasan_unpoison_vrealloc(p, size,
+ KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC);
/*
* No need to zero memory here, as unused memory will have
* already been zeroed at initial allocation time or during
_
Patches currently in -mm which might be from jiayuan.chen@linux.dev are
mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
mm-vmscan-skip-increasing-kswapd_failures-when-reclaim-was-boosted.patch
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch
2025-11-28 18:55 + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch Andrew Morton
@ 2025-12-03 15:18 ` Andrey Konovalov
2025-12-04 13:00 ` Jiayuan Chen
0 siblings, 1 reply; 5+ messages in thread
From: Andrey Konovalov @ 2025-12-03 15:18 UTC (permalink / raw)
To: jiayuan.chen, Kees Cook
Cc: mm-commits, vincenzo.frascino, urezki, stable, ryabinin.a.a,
glider, dvyukov, dakr, kasan-dev, Maciej Wieczor-Retman,
Andrew Morton
On Fri, Nov 28, 2025 at 7:55 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> The patch titled
> Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
> has been added to the -mm mm-hotfixes-unstable branch. Its filename is
> mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
>
> This patch will shortly appear at
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
>
> This patch will later appear in the mm-hotfixes-unstable branch at
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>
> The -mm tree is included into linux-next via the mm-everything
> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there every 2-3 working days
>
> ------------------------------------------------------
> From: Jiayuan Chen <jiayuan.chen@linux.dev>
> Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
> Date: Fri, 28 Nov 2025 19:15:14 +0800
Hi Jiayuan,
Please CC kasan-dev@googlegroups.com when sending KASAN patches.
>
> Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two
> issues:
>
> 1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when
> unpoisoning the extended region. This flag is required to correctly
> associate the allocation with KASAN's vmalloc tracking.
>
> Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly
> sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it.
> vrealloc must behave consistently — especially when reusing existing
> vmalloc regions — to ensure KASAN can track allocations correctly.
>
> 2. When vrealloc reuses an existing vmalloc region (without allocating new
> pages), KASAN previously generated a new tag, which broke tag-based
> memory access tracking. We now add a 'reuse_tag' parameter to
> __kasan_unpoison_vmalloc() to preserve the original tag in such cases.
I think we actually could assign a new tag to detect accesses through
the old pointer. Just gotta retag the whole region with this tag. But
this is a separate thing; filed
https://bugzilla.kernel.org/show_bug.cgi?id=220829 for this.
>
> A new helper kasan_unpoison_vralloc() is introduced to handle this reuse
> scenario, ensuring consistent tag behavior during reallocation.
>
>
> Link: https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev
> Link: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36 [1]
> Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> Reported-by: syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: Danilo Krummrich <dakr@kernel.org>
> Cc: Dmitriy Vyukov <dvyukov@google.com>
> Cc: Kees Cook <kees@kernel.org>
> Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> include/linux/kasan.h | 21 +++++++++++++++++++--
> mm/kasan/hw_tags.c | 4 ++--
> mm/kasan/shadow.c | 6 ++++--
> mm/vmalloc.c | 4 ++--
> 4 files changed, 27 insertions(+), 8 deletions(-)
>
> --- a/include/linux/kasan.h~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
> +++ a/include/linux/kasan.h
> @@ -596,13 +596,23 @@ static inline void kasan_release_vmalloc
> #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
>
> void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
> - kasan_vmalloc_flags_t flags);
> + kasan_vmalloc_flags_t flags, bool reuse_tag);
> +
> +static __always_inline void *kasan_unpoison_vrealloc(const void *start,
> + unsigned long size,
> + kasan_vmalloc_flags_t flags)
> +{
> + if (kasan_enabled())
> + return __kasan_unpoison_vmalloc(start, size, flags, true);
> + return (void *)start;
> +}
> +
> static __always_inline void *kasan_unpoison_vmalloc(const void *start,
> unsigned long size,
> kasan_vmalloc_flags_t flags)
> {
> if (kasan_enabled())
> - return __kasan_unpoison_vmalloc(start, size, flags);
> + return __kasan_unpoison_vmalloc(start, size, flags, false);
> return (void *)start;
> }
>
> @@ -629,6 +639,13 @@ static inline void kasan_release_vmalloc
> unsigned long free_region_end,
> unsigned long flags) { }
>
> +static inline void *kasan_unpoison_vrealloc(const void *start,
> + unsigned long size,
> + kasan_vmalloc_flags_t flags)
> +{
> + return (void *)start;
> +}
> +
> static inline void *kasan_unpoison_vmalloc(const void *start,
> unsigned long size,
> kasan_vmalloc_flags_t flags)
> --- a/mm/kasan/hw_tags.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
> +++ a/mm/kasan/hw_tags.c
> @@ -317,7 +317,7 @@ static void init_vmalloc_pages(const voi
> }
>
> void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
> - kasan_vmalloc_flags_t flags)
> + kasan_vmalloc_flags_t flags, bool reuse_tag)
> {
> u8 tag;
> unsigned long redzone_start, redzone_size;
> @@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi
> return (void *)start;
> }
>
> - tag = kasan_random_tag();
> + tag = reuse_tag ? get_tag(start) : kasan_random_tag();
> start = set_tag(start, tag);
>
> /* Unpoison and initialize memory up to size. */
> --- a/mm/kasan/shadow.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
> +++ a/mm/kasan/shadow.c
> @@ -625,7 +625,7 @@ void kasan_release_vmalloc(unsigned long
> }
>
> void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
> - kasan_vmalloc_flags_t flags)
> + kasan_vmalloc_flags_t flags, bool reuse_tag)
Since we already have kasan_vmalloc_flags_t, I think it makes sense to
add reuse_tag as another flag.
> {
> /*
> * Software KASAN modes unpoison both VM_ALLOC and non-VM_ALLOC
> @@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi
> !(flags & KASAN_VMALLOC_PROT_NORMAL))
> return (void *)start;
>
> - start = set_tag(start, kasan_random_tag());
> + if (!reuse_tag)
> + start = set_tag(start, kasan_random_tag());
The HW_TAGS mode should also need this fix. Please build it (the build
should be failing with your patch as is), boot it, and run the KASAN
tests. And do the same for the other modes.
Would be good to have tests for vrealloc too. Filed
https://bugzilla.kernel.org/show_bug.cgi?id=220830 for this.
> +
> kasan_unpoison(start, size, false);
> return (void *)start;
> }
> --- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
> +++ a/mm/vmalloc.c
> @@ -4175,8 +4175,8 @@ void *vrealloc_node_align_noprof(const v
> * We already have the bytes available in the allocation; use them.
> */
> if (size <= alloced_size) {
> - kasan_unpoison_vmalloc(p + old_size, size - old_size,
> - KASAN_VMALLOC_PROT_NORMAL);
> + kasan_unpoison_vrealloc(p, size,
> + KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC);
Orthogonal to this series, but is it allowed to call vrealloc on
executable mappings? If so, we need to only set
KASAN_VMALLOC_PROT_NORMAL for non-executable mappings. And
kasan_poison_vmalloc should not be called for them as well (so we
likely need to pass a protection flag to it to avoid exposing this
logic).
Kees, I see you worked on vrealloc annotations, do you happen to know?
> /*
> * No need to zero memory here, as unused memory will have
> * already been zeroed at initial allocation time or during
> _
>
> Patches currently in -mm which might be from jiayuan.chen@linux.dev are
>
> mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
> mm-vmscan-skip-increasing-kswapd_failures-when-reclaim-was-boosted.patch
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch
2025-12-03 15:18 ` Andrey Konovalov
@ 2025-12-04 13:00 ` Jiayuan Chen
2025-12-04 15:08 ` Andrey Konovalov
0 siblings, 1 reply; 5+ messages in thread
From: Jiayuan Chen @ 2025-12-04 13:00 UTC (permalink / raw)
To: Andrey Konovalov, Kees Cook
Cc: mm-commits, vincenzo.frascino, urezki, stable, ryabinin.a.a,
glider, dvyukov, dakr, kasan-dev, Maciej Wieczor-Retman,
Andrew Morton
December 3, 2025 at 23:18, "Andrey Konovalov" <andreyknvl@gmail.com mailto:andreyknvl@gmail.com?to=%22Andrey%20Konovalov%22%20%3Candreyknvl%40gmail.com%3E > wrote:
>
> > ------------------------------------------------------
> > From: Jiayuan Chen <jiayuan.chen@linux.dev>
> > Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
> > Date: Fri, 28 Nov 2025 19:15:14 +0800
> >
> Hi Jiayuan,
>
> Please CC kasan-dev@googlegroups.com when sending KASAN patches.
>
Sorry about that. I missed it.
> >
> > Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two
> > issues:
> >
> > 1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when
> > unpoisoning the extended region. This flag is required to correctly
> > associate the allocation with KASAN's vmalloc tracking.
> >
> > Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly
> > sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it.
> > vrealloc must behave consistently — especially when reusing existing
> > vmalloc regions — to ensure KASAN can track allocations correctly.
> >
> > 2. When vrealloc reuses an existing vmalloc region (without allocating new
> > pages), KASAN previously generated a new tag, which broke tag-based
> > memory access tracking. We now add a 'reuse_tag' parameter to
> > __kasan_unpoison_vmalloc() to preserve the original tag in such cases.
> >
> I think we actually could assign a new tag to detect accesses through
> the old pointer. Just gotta retag the whole region with this tag. But
> this is a separate thing; filed
> https://bugzilla.kernel.org/show_bug.cgi?id=220829 for this.
>
Thank you for your advice. I tested the following modification, and it works.
if (size <= alloced_size) {
- kasan_unpoison_vmalloc(p + old_size, size - old_size,
- KASAN_VMALLOC_PROT_NORMAL);
+ p = kasan_unpoison_vmalloc(p, size,
+ KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC);
/*
* No need to zero memory here, as unused memory will have
* already been zeroed at initial allocation time or during
* realloc shrink time.
*/
vm->requested_size = size;
return (void *)p;
}
> >
[...]
> Would be good to have tests for vrealloc too. Filed
> https://bugzilla.kernel.org/show_bug.cgi?id=220830 for this.
>
Thanks, I will add test for vrealloc in kasan_test_c.c.
> >
> > +
> > kasan_unpoison(start, size, false);
> > return (void *)start;
> > }
> > --- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
> > +++ a/mm/vmalloc.c
> > @@ -4175,8 +4175,8 @@ void *vrealloc_node_align_noprof(const v
> > * We already have the bytes available in the allocation; use them.
> > */
> > if (size <= alloced_size) {
> > - kasan_unpoison_vmalloc(p + old_size, size - old_size,
> > - KASAN_VMALLOC_PROT_NORMAL);
> > + kasan_unpoison_vrealloc(p, size,
> > + KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC);
> >
> Orthogonal to this series, but is it allowed to call vrealloc on
> executable mappings? If so, we need to only set
> KASAN_VMALLOC_PROT_NORMAL for non-executable mappings. And
> kasan_poison_vmalloc should not be called for them as well (so we
> likely need to pass a protection flag to it to avoid exposing this
> logic).
Currently, vmalloc implicitly sets kasan_flags |= KASAN_VMALLOC_VM_ALLOC, meaning the allocated
memory cannot be used for executable code segments. I think we could require users to explicitly
pass a flag indicating whether KASAN should be enabled — this would make the function’s intent
clearer and more explicit to the caller.
>
> Kees, I see you worked on vrealloc annotations, do you happen to know?
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch
2025-12-04 13:00 ` Jiayuan Chen
@ 2025-12-04 15:08 ` Andrey Konovalov
0 siblings, 0 replies; 5+ messages in thread
From: Andrey Konovalov @ 2025-12-04 15:08 UTC (permalink / raw)
To: Jiayuan Chen
Cc: Kees Cook, mm-commits, vincenzo.frascino, urezki, stable,
ryabinin.a.a, glider, dvyukov, dakr, kasan-dev,
Maciej Wieczor-Retman, Andrew Morton
On Thu, Dec 4, 2025 at 2:00 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> December 3, 2025 at 23:18, "Andrey Konovalov" <andreyknvl@gmail.com mailto:andreyknvl@gmail.com?to=%22Andrey%20Konovalov%22%20%3Candreyknvl%40gmail.com%3E > wrote:
>
>
> >
>
> > > ------------------------------------------------------
> > > From: Jiayuan Chen <jiayuan.chen@linux.dev>
> > > Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
> > > Date: Fri, 28 Nov 2025 19:15:14 +0800
> > >
> > Hi Jiayuan,
> >
> > Please CC kasan-dev@googlegroups.com when sending KASAN patches.
> >
>
> Sorry about that. I missed it.
>
> > >
> > > Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two
> > > issues:
> > >
> > > 1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when
> > > unpoisoning the extended region. This flag is required to correctly
> > > associate the allocation with KASAN's vmalloc tracking.
> > >
> > > Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly
> > > sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it.
> > > vrealloc must behave consistently — especially when reusing existing
> > > vmalloc regions — to ensure KASAN can track allocations correctly.
> > >
> > > 2. When vrealloc reuses an existing vmalloc region (without allocating new
> > > pages), KASAN previously generated a new tag, which broke tag-based
> > > memory access tracking. We now add a 'reuse_tag' parameter to
> > > __kasan_unpoison_vmalloc() to preserve the original tag in such cases.
> > >
> > I think we actually could assign a new tag to detect accesses through
> > the old pointer. Just gotta retag the whole region with this tag. But
> > this is a separate thing; filed
> > https://bugzilla.kernel.org/show_bug.cgi?id=220829 for this.
> >
>
> Thank you for your advice. I tested the following modification, and it works.
>
> if (size <= alloced_size) {
> - kasan_unpoison_vmalloc(p + old_size, size - old_size,
> - KASAN_VMALLOC_PROT_NORMAL);
> + p = kasan_unpoison_vmalloc(p, size,
> + KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC);
> /*
> * No need to zero memory here, as unused memory will have
> * already been zeroed at initial allocation time or during
> * realloc shrink time.
> */
> vm->requested_size = size;
> return (void *)p;
> }
>
>
> > >
> [...]
> > Would be good to have tests for vrealloc too. Filed
> > https://bugzilla.kernel.org/show_bug.cgi?id=220830 for this.
> >
>
> Thanks, I will add test for vrealloc in kasan_test_c.c.
Awesome!
But as mentioned in the other thread, let's first implement a
standalone fix for the original issue (that can be backported) and all
these extra additions can come as separate patches on top.
Thank you!
^ permalink raw reply [flat|nested] 5+ messages in thread
* + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch
@ 2025-12-04 22:21 Andrew Morton
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Morton @ 2025-12-04 22:21 UTC (permalink / raw)
To: mm-commits, vincenzo.frascino, urezki, stable, ryabinin.a.a,
maciej.wieczor-retman, kees, glider, elver, dvyukov, dakr,
andreyknvl, jiayuan.chen, akpm
The patch titled
Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Jiayuan Chen <jiayuan.chen@linux.dev>
Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN
Date: Thu, 04 Dec 2025 18:59:55 +0000
Patch series "kasan: vmalloc: Fixes for the percpu allocator and
vrealloc", v3.
Patches fix two issues related to KASAN and vmalloc.
The first one, a KASAN tag mismatch, possibly resulting in a kernel panic,
can be observed on systems with a tag-based KASAN enabled and with
multiple NUMA nodes. Initially it was only noticed on x86 [1] but later a
similar issue was also reported on arm64 [2].
Specifically the problem is related to how vm_structs interact with
pcpu_chunks - both when they are allocated, assigned and when pcpu_chunk
addresses are derived.
When vm_structs are allocated they are unpoisoned, each with a different
random tag, if vmalloc support is enabled along the KASAN mode. Later
when first pcpu chunk is allocated it gets its 'base_addr' field set to
the first allocated vm_struct. With that it inherits that vm_struct's
tag.
When pcpu_chunk addresses are later derived (by pcpu_chunk_addr(), for
example in pcpu_alloc_noprof()) the base_addr field is used and offsets
are added to it. If the initial conditions are satisfied then some of the
offsets will point into memory allocated with a different vm_struct. So
while the lower bits will get accurately derived the tag bits in the top
of the pointer won't match the shadow memory contents.
The solution (proposed at v2 of the x86 KASAN series [3]) is to unpoison
the vm_structs with the same tag when allocating them for the per cpu
allocator (in pcpu_get_vm_areas()).
The second one reported by syzkaller [4] is related to vrealloc and
happens because of random tag generation when unpoisoning memory without
allocating new pages. This breaks shadow memory tracking and needs to
reuse the existing tag instead of generating a new one. At the same time
an inconsistency in used flags is corrected.
This patch (of 3):
Syzkaller reported a memory out-of-bounds bug [4]. This patch fixes two
issues:
1. In vrealloc the KASAN_VMALLOC_VM_ALLOC flag is missing when
unpoisoning the extended region. This flag is required to correctly
associate the allocation with KASAN's vmalloc tracking.
Note: In contrast, vzalloc (via __vmalloc_node_range_noprof)
explicitly sets KASAN_VMALLOC_VM_ALLOC and calls
kasan_unpoison_vmalloc() with it. vrealloc must behave consistently --
especially when reusing existing vmalloc regions -- to ensure KASAN can
track allocations correctly.
2. When vrealloc reuses an existing vmalloc region (without allocating
new pages) KASAN generates a new tag, which breaks tag-based memory
access tracking.
Introduce KASAN_VMALLOC_KEEP_TAG, a new KASAN flag that allows reusing the
tag already attached to the pointer, ensuring consistent tag behavior
during reallocation.
Pass KASAN_VMALLOC_KEEP_TAG and KASAN_VMALLOC_VM_ALLOC to the
kasan_unpoison_vmalloc inside vrealloc_node_align_noprof().
Link: https://lkml.kernel.org/r/38dece0a4074c43e48150d1e242f8242c73bf1a5.1764874575.git.m.wieczorretman@pm.me
Link: https://lore.kernel.org/all/e7e04692866d02e6d3b32bb43b998e5d17092ba4.1738686764.git.maciej.wieczor-retman@intel.com/ [1]
Link: https://lore.kernel.org/all/aMUrW1Znp1GEj7St@MiWiFi-R3L-srv/ [2]
Link: https://lore.kernel.org/all/CAPAsAGxDRv_uFeMYu9TwhBVWHCCtkSxoWY4xmFB_vowMbi8raw@mail.gmail.com/ [3]
Link: https://syzkaller.appspot.com/bug?extid=3D997752115a851cb0cf36 [4]
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Co-developed-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing"
)
Reported-by: syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Marco Elver <elver@google.com>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/kasan.h | 1 +
mm/kasan/hw_tags.c | 2 +-
mm/kasan/shadow.c | 4 +++-
mm/vmalloc.c | 4 +++-
4 files changed, 8 insertions(+), 3 deletions(-)
--- a/include/linux/kasan.h~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/include/linux/kasan.h
@@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vma
#define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u)
#define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u)
#define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u)
+#define KASAN_VMALLOC_KEEP_TAG ((__force kasan_vmalloc_flags_t)0x08u)
#define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply exsiting page range */
#define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */
--- a/mm/kasan/hw_tags.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/mm/kasan/hw_tags.c
@@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi
return (void *)start;
}
- tag = kasan_random_tag();
+ tag = (flags & KASAN_VMALLOC_KEEP_TAG) ? get_tag(start) : kasan_random_tag();
start = set_tag(start, tag);
/* Unpoison and initialize memory up to size. */
--- a/mm/kasan/shadow.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/mm/kasan/shadow.c
@@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi
!(flags & KASAN_VMALLOC_PROT_NORMAL))
return (void *)start;
- start = set_tag(start, kasan_random_tag());
+ if (unlikely(!(flags & KASAN_VMALLOC_KEEP_TAG)))
+ start = set_tag(start, kasan_random_tag());
+
kasan_unpoison(start, size, false);
return (void *)start;
}
--- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan
+++ a/mm/vmalloc.c
@@ -4176,7 +4176,9 @@ void *vrealloc_node_align_noprof(const v
*/
if (size <= alloced_size) {
kasan_unpoison_vmalloc(p + old_size, size - old_size,
- KASAN_VMALLOC_PROT_NORMAL);
+ KASAN_VMALLOC_PROT_NORMAL |
+ KASAN_VMALLOC_VM_ALLOC |
+ KASAN_VMALLOC_KEEP_TAG);
/*
* No need to zero memory here, as unused memory will have
* already been zeroed at initial allocation time or during
_
Patches currently in -mm which might be from jiayuan.chen@linux.dev are
mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-04 22:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-28 18:55 + mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch Andrew Morton
2025-12-03 15:18 ` Andrey Konovalov
2025-12-04 13:00 ` Jiayuan Chen
2025-12-04 15:08 ` Andrey Konovalov
-- strict thread matches above, loose matches on Subject: below --
2025-12-04 22:21 Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).