On 2025-12-03 at 16:53:01 +0100, Andrey Konovalov wrote:

On Tue, Dec 2, 2025 at 3:29 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 modified __kasan_unpoison_vmalloc() to pass the tag of the first vm_struct's address when vm_structs are unpoisoned in pcpu_get_vm_areas(). 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 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 | 3 ++- mm/kasan/hw_tags.c | 12 ++++++++---- mm/kasan/shadow.c | 15 +++++++++++---- 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/mm/kasan/common.c b/mm/kasan/common.c index 7884ea7d13f9..e5a867a5670b 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -591,11 +591,12 @@ void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, unsigned long size; void *addr; int area;

•   u8 tag = get_tag(vms[0]->addr);
  
    for (area = 0 ; area < nr_vms ; area++) {
            size = vms[area]->size;
            addr = vms[area]->addr;
  

•           vms[area]->addr = __kasan_unpoison_vmap_areas(addr, size, flags);
  

•           vms[area]->addr = __kasan_unpoison_vmap_areas(addr, size, flags, tag);
  

I'm thinking what you can do here is:

vms[area]->addr = set_tag(addr, tag); __kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG);

I noticed that something like this wouldn't work once I started trying to rebase my work onto Jiayuan's. The line: + u8 tag = get_tag(vms[0]->addr); is wrong and should be + u8 tag = kasan_random_tag(); I was sure the vms[0]->addr was already tagged (I recall checking this so I'm not sure if something changed or my previous check was wrong) but the problem here is that vms[0]->addr, vms[1]->addr ... were unpoisoned with random addresses, specifically different random addresses. So then later in the pcpu chunk code vms[1] related pointers would get the tag from vms[0]->addr.

So I think we still need a separate way to do __kasan_unpoison_vmalloc with a specific tag.

This is with the assumption that Jiayuan's patch is changed to add KASAN_VMALLOC_KEEP_TAG to kasan_vmalloc_flags_t.

Then you should not need that extra __kasan_random_unpoison_vmalloc helper.

I already rewrote the patch rebased onto Jiayuan's patch. I was able to ditch the __kasan_random_unpoison_vmalloc but I needed to add __kasan_unpoison_vrealloc - so I can pass the tag of the start pointer to __kasan_unpoison_vmalloc. I was hoping to post it today/tomorrow so Jiayuan can check my changes don't break his solution. I'm just waiting to check it compiles against all the fun kernel configs.