[PATCH v3 0/3] kasan: vmalloc: Fixes for the percpu allocator and vrealloc

[PATCH v3 0/3] kasan: vmalloc: Fixes for the percpu allocator and vrealloc

[Maciej Wieczor-Retman]

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.

The series is based on 6.18.

[1] https://lore.kernel.org/all/e7e04692866d02e6d3b32bb43b998e5d17092ba4.1738686764.git.maciej.wieczor-retman@intel.com/
[2] https://lore.kernel.org/all/aMUrW1Znp1GEj7St@MiWiFi-R3L-srv/
[3] https://lore.kernel.org/all/CAPAsAGxDRv_uFeMYu9TwhBVWHCCtkSxoWY4xmFB_vowMbi8raw@mail.gmail.com/
[4] https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36

Changes v3:
- Reworded the 4th and 5th paragraphs after finding the vms[] pointers
  were untagged.
- Redo the patches by using a flag instead of a new
  __kasan_vmalloc_unpoison() argument.
- Added Jiayuan's patch to the series.

Changes v2:
- Redid the patches since last version wasn't an actual refactor as the
  patch promised.
- Also fixed multiple mistakes and retested everything.

Jiayuan Chen (1):
  mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN

Maciej Wieczor-Retman (2):
  kasan: Refactor pcpu kasan vmalloc unpoison
  kasan: Unpoison vms[area] addresses with a common tag

 include/linux/kasan.h | 16 ++++++++++++++++
 mm/kasan/common.c     | 34 ++++++++++++++++++++++++++++++++++
 mm/kasan/hw_tags.c    |  2 +-
 mm/kasan/shadow.c     |  4 +++-
 mm/vmalloc.c          |  8 ++++----
 5 files changed, 58 insertions(+), 6 deletions(-)

-- 
2.52.0

[PATCH v3 1/3] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN

[Maciej Wieczor-Retman]

From: Jiayuan Chen <jiayuan.chen@linux.dev>

Syzkaller reported a memory out-of-bounds bug [1]. 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().

[1]: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36

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/
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>
---
 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(-)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index d12e1a5f5a9a..6d7972bb390c 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t;
 #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 */
diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
index 1c373cc4b3fa..cbef5e450954 100644
--- a/mm/kasan/hw_tags.c
+++ b/mm/kasan/hw_tags.c
@@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
 		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. */
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index 5d2a876035d6..5e47ae7fdd59 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
 	    !(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;
 }
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 798b2ed21e46..22a73a087135 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4176,7 +4176,9 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
 	 */
 	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
-- 
2.52.0

Re: [PATCH v3 1/3] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN

[Andrey Konovalov]

On Thu, Dec 4, 2025 at 8:00 PM Maciej Wieczor-Retman
<m.wieczorretman@pm.me> wrote:
>
> From: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> Syzkaller reported a memory out-of-bounds bug [1]. 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().
>
> [1]: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36
>
> 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/
> 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>
> ---
>  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(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index d12e1a5f5a9a..6d7972bb390c 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t;
>  #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 */
> diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
> index 1c373cc4b3fa..cbef5e450954 100644
> --- a/mm/kasan/hw_tags.c
> +++ b/mm/kasan/hw_tags.c
> @@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
>                 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. */
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index 5d2a876035d6..5e47ae7fdd59 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
>             !(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;
>  }
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 798b2ed21e46..22a73a087135 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4176,7 +4176,9 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
>          */
>         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
> --
> 2.52.0
>

Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>

[PATCH v3 2/3] kasan: Refactor pcpu kasan vmalloc unpoison

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

A KASAN tag mismatch, possibly causing a kernel panic, can be observed
on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
It was reported on arm64 and reproduced on x86. It can be explained in
the following points:

	1. There can be more than one virtual memory chunk.
	2. Chunk's base address has a tag.
	3. The base address points at the first chunk and thus inherits
	   the tag of the first chunk.
	4. The subsequent chunks will be accessed with the tag from the
	   first chunk.
	5. Thus, the subsequent chunks need to have their tag set to
	   match that of the first chunk.

Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in
preparation for the actual fix.

Changelog v1 (after splitting of from the KASAN series):
- Rewrite first paragraph of the patch message to point at the user
  impact of the issue.
- Move helper to common.c so it can be compiled in all KASAN modes.

Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS")
Cc: <stable@vger.kernel.org> # 6.1+
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v3:
- Redo the patch after applying Andrey's comments to align the code more
  with what's already in include/linux/kasan.h

Changelog v2:
- Redo the whole patch so it's an actual refactor.

 include/linux/kasan.h | 15 +++++++++++++++
 mm/kasan/common.c     | 17 +++++++++++++++++
 mm/vmalloc.c          |  4 +---
 3 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 6d7972bb390c..cde493cb7702 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -615,6 +615,16 @@ static __always_inline void kasan_poison_vmalloc(const void *start,
 		__kasan_poison_vmalloc(start, size);
 }
 
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+				 kasan_vmalloc_flags_t flags);
+static __always_inline void
+kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+			  kasan_vmalloc_flags_t flags)
+{
+	if (kasan_enabled())
+		__kasan_unpoison_vmap_areas(vms, nr_vms, flags);
+}
+
 #else /* CONFIG_KASAN_VMALLOC */
 
 static inline void kasan_populate_early_vm_area_shadow(void *start,
@@ -639,6 +649,11 @@ static inline void *kasan_unpoison_vmalloc(const void *start,
 static inline void kasan_poison_vmalloc(const void *start, unsigned long size)
 { }
 
+static __always_inline void
+kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+			  kasan_vmalloc_flags_t flags)
+{ }
+
 #endif /* CONFIG_KASAN_VMALLOC */
 
 #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index d4c14359feaf..1ed6289d471a 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -28,6 +28,7 @@
 #include <linux/string.h>
 #include <linux/types.h>
 #include <linux/bug.h>
+#include <linux/vmalloc.h>
 
 #include "kasan.h"
 #include "../slab.h"
@@ -582,3 +583,19 @@ bool __kasan_check_byte(const void *address, unsigned long ip)
 	}
 	return true;
 }
+
+#ifdef CONFIG_KASAN_VMALLOC
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+				 kasan_vmalloc_flags_t flags)
+{
+	unsigned long size;
+	void *addr;
+	int area;
+
+	for (area = 0 ; area < nr_vms ; area++) {
+		size = vms[area]->size;
+		addr = vms[area]->addr;
+		vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
+	}
+}
+#endif
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 22a73a087135..33e705ccafba 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4872,9 +4872,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
 	 * With hardware tag-based KASAN, marking is skipped for
 	 * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
 	 */
-	for (area = 0; area < nr_vms; area++)
-		vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr,
-				vms[area]->size, KASAN_VMALLOC_PROT_NORMAL);
+	kasan_unpoison_vmap_areas(vms, nr_vms, KASAN_VMALLOC_PROT_NORMAL);
 
 	kfree(vas);
 	return vms;
-- 
2.52.0

Re: [PATCH v3 2/3] kasan: Refactor pcpu kasan vmalloc unpoison

[Andrey Konovalov]

On Thu, Dec 4, 2025 at 8:00 PM Maciej Wieczor-Retman
<m.wieczorretman@pm.me> wrote:
>
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> A KASAN tag mismatch, possibly causing a kernel panic, can be observed
> on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
> It was reported on arm64 and reproduced on x86. It can be explained in
> the following points:
>
>         1. There can be more than one virtual memory chunk.
>         2. Chunk's base address has a tag.
>         3. The base address points at the first chunk and thus inherits
>            the tag of the first chunk.
>         4. The subsequent chunks will be accessed with the tag from the
>            first chunk.
>         5. Thus, the subsequent chunks need to have their tag set to
>            match that of the first chunk.
>
> Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in
> preparation for the actual fix.
>
> Changelog v1 (after splitting of from the KASAN series):
> - Rewrite first paragraph of the patch message to point at the user
>   impact of the issue.
> - Move helper to common.c so it can be compiled in all KASAN modes.

Nit: Can put this part after ---.

>
> Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS")
> Cc: <stable@vger.kernel.org> # 6.1+
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> ---
> Changelog v3:
> - Redo the patch after applying Andrey's comments to align the code more
>   with what's already in include/linux/kasan.h
>
> Changelog v2:
> - Redo the whole patch so it's an actual refactor.
>
>  include/linux/kasan.h | 15 +++++++++++++++
>  mm/kasan/common.c     | 17 +++++++++++++++++
>  mm/vmalloc.c          |  4 +---
>  3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 6d7972bb390c..cde493cb7702 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -615,6 +615,16 @@ static __always_inline void kasan_poison_vmalloc(const void *start,
>                 __kasan_poison_vmalloc(start, size);
>  }
>
> +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> +                                kasan_vmalloc_flags_t flags);
> +static __always_inline void
> +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> +                         kasan_vmalloc_flags_t flags)
> +{
> +       if (kasan_enabled())
> +               __kasan_unpoison_vmap_areas(vms, nr_vms, flags);
> +}
> +
>  #else /* CONFIG_KASAN_VMALLOC */
>
>  static inline void kasan_populate_early_vm_area_shadow(void *start,
> @@ -639,6 +649,11 @@ static inline void *kasan_unpoison_vmalloc(const void *start,
>  static inline void kasan_poison_vmalloc(const void *start, unsigned long size)
>  { }
>
> +static __always_inline void
> +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> +                         kasan_vmalloc_flags_t flags)
> +{ }
> +
>  #endif /* CONFIG_KASAN_VMALLOC */
>
>  #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index d4c14359feaf..1ed6289d471a 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -28,6 +28,7 @@
>  #include <linux/string.h>
>  #include <linux/types.h>
>  #include <linux/bug.h>
> +#include <linux/vmalloc.h>
>
>  #include "kasan.h"
>  #include "../slab.h"
> @@ -582,3 +583,19 @@ bool __kasan_check_byte(const void *address, unsigned long ip)
>         }
>         return true;
>  }
> +
> +#ifdef CONFIG_KASAN_VMALLOC
> +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> +                                kasan_vmalloc_flags_t flags)
> +{
> +       unsigned long size;
> +       void *addr;
> +       int area;
> +
> +       for (area = 0 ; area < nr_vms ; area++) {
> +               size = vms[area]->size;
> +               addr = vms[area]->addr;
> +               vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
> +       }
> +}
> +#endif
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 22a73a087135..33e705ccafba 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4872,9 +4872,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
>          * With hardware tag-based KASAN, marking is skipped for
>          * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
>          */
> -       for (area = 0; area < nr_vms; area++)
> -               vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr,
> -                               vms[area]->size, KASAN_VMALLOC_PROT_NORMAL);
> +       kasan_unpoison_vmap_areas(vms, nr_vms, KASAN_VMALLOC_PROT_NORMAL);
>
>         kfree(vas);
>         return vms;
> --
> 2.52.0
>

Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>

Re: [PATCH v3 2/3] kasan: Refactor pcpu kasan vmalloc unpoison

[Maciej Wieczór-Retman]

On 2025-12-05 at 02:09:02 +0100, Andrey Konovalov wrote:
>On Thu, Dec 4, 2025 at 8:00 PM Maciej Wieczor-Retman
><m.wieczorretman@pm.me> wrote:
>>
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>>
>> A KASAN tag mismatch, possibly causing a kernel panic, can be observed
>> on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
>> It was reported on arm64 and reproduced on x86. It can be explained in
>> the following points:
>>
>>         1. There can be more than one virtual memory chunk.
>>         2. Chunk's base address has a tag.
>>         3. The base address points at the first chunk and thus inherits
>>            the tag of the first chunk.
>>         4. The subsequent chunks will be accessed with the tag from the
>>            first chunk.
>>         5. Thus, the subsequent chunks need to have their tag set to
>>            match that of the first chunk.
>>
>> Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in
>> preparation for the actual fix.
>>
>> Changelog v1 (after splitting of from the KASAN series):
>> - Rewrite first paragraph of the patch message to point at the user
>>   impact of the issue.
>> - Move helper to common.c so it can be compiled in all KASAN modes.
>
>Nit: Can put this part after ---.

Thanks for noticing that, guess I need to revise my script that moves
these under the three dashes

...

-- 
Kind regards
Maciej Wieczór-Retman

[PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

A KASAN tag mismatch, possibly causing a kernel panic, can be observed
on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
It was reported on arm64 and reproduced on x86. It can be explained in
the following points:

	1. There can be more than one virtual memory chunk.
	2. Chunk's base address has a tag.
	3. The base address points at the first chunk and thus inherits
	   the tag of the first chunk.
	4. The subsequent chunks will be accessed with the tag from the
	   first chunk.
	5. Thus, the subsequent chunks need to have their tag set to
	   match that of the first chunk.

Use the new vmalloc flag that disables random tag assignment in
__kasan_unpoison_vmalloc() - pass the same random tag to all the
vm_structs by tagging the pointers before they go inside
__kasan_unpoison_vmalloc(). Assigning a common tag resolves the pcpu
chunk address mismatch.

Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS")
Cc: <stable@vger.kernel.org> # 6.1+
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v3:
- Redo the patch by using a flag instead of a new argument in
  __kasan_unpoison_vmalloc() (Andrey Konovalov)

Changelog v2:
- Revise the whole patch to match the fixed refactorization from the
  first patch.

Changelog v1:
- Rewrite the patch message to point at the user impact of the issue.
- Move helper to common.c so it can be compiled in all KASAN modes.

 mm/kasan/common.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 1ed6289d471a..496bb2c56911 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -591,11 +591,28 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
 	unsigned long size;
 	void *addr;
 	int area;
+	u8 tag;
+
+	/*
+	 * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers
+	 * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
+	 * KASAN checks down the line.
+	 */
+	if (flags & KASAN_VMALLOC_KEEP_TAG) {
+		pr_warn("KASAN_VMALLOC_KEEP_TAG flag shouldn't be already set!\n");
+		return;
+	}
+
+	size = vms[0]->size;
+	addr = vms[0]->addr;
+	vms[0]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
+	tag = get_tag(vms[0]->addr);
 
-	for (area = 0 ; area < nr_vms ; area++) {
+	for (area = 1 ; area < nr_vms ; area++) {
 		size = vms[area]->size;
-		addr = vms[area]->addr;
-		vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
+		addr = set_tag(vms[area]->addr, tag);
+		vms[area]->addr =
+			__kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG);
 	}
 }
 #endif
-- 
2.52.0

Re: [PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag

[Andrey Konovalov]

On Thu, Dec 4, 2025 at 8:00 PM Maciej Wieczor-Retman
<m.wieczorretman@pm.me> wrote:
>
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> A KASAN tag mismatch, possibly causing a kernel panic, can be observed
> on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
> It was reported on arm64 and reproduced on x86. It can be explained in
> the following points:
>
>         1. There can be more than one virtual memory chunk.
>         2. Chunk's base address has a tag.
>         3. The base address points at the first chunk and thus inherits
>            the tag of the first chunk.
>         4. The subsequent chunks will be accessed with the tag from the
>            first chunk.
>         5. Thus, the subsequent chunks need to have their tag set to
>            match that of the first chunk.
>
> Use the new vmalloc flag that disables random tag assignment in
> __kasan_unpoison_vmalloc() - pass the same random tag to all the
> vm_structs by tagging the pointers before they go inside
> __kasan_unpoison_vmalloc(). Assigning a common tag resolves the pcpu
> chunk address mismatch.
>
> Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS")
> Cc: <stable@vger.kernel.org> # 6.1+
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> ---
> Changelog v3:
> - Redo the patch by using a flag instead of a new argument in
>   __kasan_unpoison_vmalloc() (Andrey Konovalov)
>
> Changelog v2:
> - Revise the whole patch to match the fixed refactorization from the
>   first patch.
>
> Changelog v1:
> - Rewrite the patch message to point at the user impact of the issue.
> - Move helper to common.c so it can be compiled in all KASAN modes.
>
>  mm/kasan/common.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 1ed6289d471a..496bb2c56911 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -591,11 +591,28 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
>         unsigned long size;
>         void *addr;
>         int area;
> +       u8 tag;
> +
> +       /*
> +        * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers
> +        * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
> +        * KASAN checks down the line.
> +        */
> +       if (flags & KASAN_VMALLOC_KEEP_TAG) {

I think we can do a WARN_ON() here: passing KASAN_VMALLOC_KEEP_TAG to
this function would be a bug in KASAN annotations and thus a kernel
bug. Therefore, printing a WARNING seems justified.

> +               pr_warn("KASAN_VMALLOC_KEEP_TAG flag shouldn't be already set!\n");
> +               return;
> +       }
> +
> +       size = vms[0]->size;
> +       addr = vms[0]->addr;
> +       vms[0]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
> +       tag = get_tag(vms[0]->addr);
>
> -       for (area = 0 ; area < nr_vms ; area++) {
> +       for (area = 1 ; area < nr_vms ; area++) {
>                 size = vms[area]->size;
> -               addr = vms[area]->addr;
> -               vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
> +               addr = set_tag(vms[area]->addr, tag);
> +               vms[area]->addr =
> +                       __kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG);
>         }
>  }
>  #endif
> --
> 2.52.0
>

With WARN_ON():

Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>

Thank you!

Re: [PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag

[Andrew Morton]

On Fri, 5 Dec 2025 02:09:06 +0100 Andrey Konovalov <andreyknvl@gmail.com> wrote:

> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -591,11 +591,28 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> >         unsigned long size;
> >         void *addr;
> >         int area;
> > +       u8 tag;
> > +
> > +       /*
> > +        * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers
> > +        * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
> > +        * KASAN checks down the line.
> > +        */
> > +       if (flags & KASAN_VMALLOC_KEEP_TAG) {
> 
> I think we can do a WARN_ON() here: passing KASAN_VMALLOC_KEEP_TAG to
> this function would be a bug in KASAN annotations and thus a kernel
> bug. Therefore, printing a WARNING seems justified.

This?

--- a/mm/kasan/common.c~kasan-unpoison-vms-addresses-with-a-common-tag-fix
+++ a/mm/kasan/common.c
@@ -598,7 +598,7 @@ void __kasan_unpoison_vmap_areas(struct
 	 * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
 	 * KASAN checks down the line.
 	 */
-	if (flags & KASAN_VMALLOC_KEEP_TAG) {
+	if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG)) {
 		pr_warn("KASAN_VMALLOC_KEEP_TAG flag shouldn't be already set!\n");
 		return;
 	}
_

Re: [PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag

[Andrey Konovalov]

On Fri, Dec 5, 2025 at 4:22 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 5 Dec 2025 02:09:06 +0100 Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> > > --- a/mm/kasan/common.c
> > > +++ b/mm/kasan/common.c
> > > @@ -591,11 +591,28 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> > >         unsigned long size;
> > >         void *addr;
> > >         int area;
> > > +       u8 tag;
> > > +
> > > +       /*
> > > +        * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers
> > > +        * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
> > > +        * KASAN checks down the line.
> > > +        */
> > > +       if (flags & KASAN_VMALLOC_KEEP_TAG) {
> >
> > I think we can do a WARN_ON() here: passing KASAN_VMALLOC_KEEP_TAG to
> > this function would be a bug in KASAN annotations and thus a kernel
> > bug. Therefore, printing a WARNING seems justified.
>
> This?
>
> --- a/mm/kasan/common.c~kasan-unpoison-vms-addresses-with-a-common-tag-fix
> +++ a/mm/kasan/common.c
> @@ -598,7 +598,7 @@ void __kasan_unpoison_vmap_areas(struct
>          * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
>          * KASAN checks down the line.
>          */
> -       if (flags & KASAN_VMALLOC_KEEP_TAG) {
> +       if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG)) {
>                 pr_warn("KASAN_VMALLOC_KEEP_TAG flag shouldn't be already set!\n");
>                 return;
>         }
> _
>

Can also drop pr_warn(), but this is fine too. Thanks!

Re: [PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag

[Maciej Wieczór-Retman]

Thanks for checking the patches out, do you want me to send v4 with this
correction or is it redundant now that Andrew already wrote it?

Kind regards
Maciej Wieczór-Retman

On 2025-12-05 at 04:38:27 +0100, Andrey Konovalov wrote:
>On Fri, Dec 5, 2025 at 4:22 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> On Fri, 5 Dec 2025 02:09:06 +0100 Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> > > --- a/mm/kasan/common.c
>> > > +++ b/mm/kasan/common.c
>> > > @@ -591,11 +591,28 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
>> > >         unsigned long size;
>> > >         void *addr;
>> > >         int area;
>> > > +       u8 tag;
>> > > +
>> > > +       /*
>> > > +        * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers
>> > > +        * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
>> > > +        * KASAN checks down the line.
>> > > +        */
>> > > +       if (flags & KASAN_VMALLOC_KEEP_TAG) {
>> >
>> > I think we can do a WARN_ON() here: passing KASAN_VMALLOC_KEEP_TAG to
>> > this function would be a bug in KASAN annotations and thus a kernel
>> > bug. Therefore, printing a WARNING seems justified.
>>
>> This?
>>
>> --- a/mm/kasan/common.c~kasan-unpoison-vms-addresses-with-a-common-tag-fix
>> +++ a/mm/kasan/common.c
>> @@ -598,7 +598,7 @@ void __kasan_unpoison_vmap_areas(struct
>>          * would be unpoisoned with the KASAN_TAG_KERNEL which would disable
>>          * KASAN checks down the line.
>>          */
>> -       if (flags & KASAN_VMALLOC_KEEP_TAG) {
>> +       if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG)) {
>>                 pr_warn("KASAN_VMALLOC_KEEP_TAG flag shouldn't be already set!\n");
>>                 return;
>>         }
>> _
>>
>
>Can also drop pr_warn(), but this is fine too. Thanks!

Re: [PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag

[Andrey Konovalov]

On Fri, Dec 5, 2025 at 8:55 AM Maciej Wieczór-Retman
<m.wieczorretman@pm.me> wrote:
>
> Thanks for checking the patches out, do you want me to send v4 with this
> correction or is it redundant now that Andrew already wrote it?

Either way is fine with me, thanks!

Re: [PATCH v3 0/3] kasan: vmalloc: Fixes for the percpu allocator and vrealloc

[Andrew Morton]

On Thu, 04 Dec 2025 18:57:44 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:

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

I added cc:stable to [1/3], unless its omission was intentional?

Re: [PATCH v3 0/3] kasan: vmalloc: Fixes for the percpu allocator and vrealloc

[Maciej Wieczór-Retman]

On 2025-12-04 at 14:21:12 -0800, Andrew Morton wrote:
>On Thu, 04 Dec 2025 18:57:44 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
>
>> 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].
>>
>> ...
>>
>
>I added cc:stable to [1/3], unless its omission was intentional?

Thank you for adding it, I forgot it was missing

-- 
Kind regards
Maciej Wieczór-Retman