include/linux/kasan.h | 16 +++++++++++++--- mm/kasan/common.c | 18 ++++++++++++++++++ mm/kasan/hw_tags.c | 21 ++++++++++++++++++--- mm/kasan/shadow.c | 25 ++++++++++++++++++++++--- mm/vmalloc.c | 4 +--- 5 files changed, 72 insertions(+), 12 deletions(-)
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 tagged 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 tag the vm_structs the same when allocating them for the per cpu allocator (in pcpu_get_vm_areas()). Originally these patches were part of the x86 KASAN series [4]. 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://lore.kernel.org/all/cover.1761763681.git.m.wieczorretman@pm.me/ Changes v2: - Redid the patches since last version wasn't an actual refactor as the patch promised. - Also fixed multiple mistakes and retested everything. 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 | 18 ++++++++++++++++++ mm/kasan/hw_tags.c | 21 ++++++++++++++++++--- mm/kasan/shadow.c | 25 ++++++++++++++++++++++--- mm/vmalloc.c | 4 +--- 5 files changed, 72 insertions(+), 12 deletions(-) -- 2.52.0
On Tue, 02 Dec 2025 14:27:56 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote: > 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 tagged 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 tag the > vm_structs the same when allocating them for the per cpu allocator (in > pcpu_get_vm_areas()). > > Originally these patches were part of the x86 KASAN series [4]. > > The series is based on 6.18. This series overlaps a lot with https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev Please discuss! > [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://lore.kernel.org/all/cover.1761763681.git.m.wieczorretman@pm.me/ >
On 2025-12-02 at 08:35:22 -0800, Andrew Morton wrote: >On Tue, 02 Dec 2025 14:27:56 +0000 Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote: ... > >This series overlaps a lot with > >https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev > >Please discuss! > Thanks for pointing it out, I'll test if Jiayuan's version of __kasan_unpoison_vmalloc fixes the issue I'm seeing. kind regards Maciej Wieczór-Retman
© 2016 - 2026 Red Hat, Inc.