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
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!
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; } _
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!
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!
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!
linux-stable-mirror@lists.linaro.org
-
Andrew Morton -
Andrey Konovalov -
Maciej Wieczor-Retman -
Maciej Wieczór-Retman