From: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
To: akpm@linux-foundation.org, urezki@gmail.com, dakr@kernel.org,
vincenzo.frascino@arm.com, ryabinin.a.a@gmail.com,
andreyknvl@gmail.com, kees@kernel.org, elver@google.com,
glider@google.com, dvyukov@google.com
Cc: jiayuan.chen@linux.dev, kasan-dev@googlegroups.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
m.wieczorretman@pm.me
Subject: [PATCH v3 0/3] kasan: vmalloc: Fixes for the percpu allocator and vrealloc
Date: Thu, 04 Dec 2025 18:57:44 +0000 [thread overview]
Message-ID: <cover.1764874575.git.m.wieczorretman@pm.me> (raw)
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
next reply other threads:[~2025-12-04 18:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-04 18:57 Maciej Wieczor-Retman [this message]
2025-12-04 18:59 ` [PATCH v3 1/3] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN Maciej Wieczor-Retman
2025-12-05 1:08 ` Andrey Konovalov
2025-12-04 19:00 ` [PATCH v3 2/3] kasan: Refactor pcpu kasan vmalloc unpoison Maciej Wieczor-Retman
2025-12-05 1:09 ` Andrey Konovalov
2025-12-05 8:01 ` Maciej Wieczór-Retman
2025-12-04 19:00 ` [PATCH v3 3/3] kasan: Unpoison vms[area] addresses with a common tag Maciej Wieczor-Retman
2025-12-05 1:09 ` Andrey Konovalov
2025-12-05 3:22 ` Andrew Morton
2025-12-05 3:38 ` Andrey Konovalov
2025-12-05 7:55 ` Maciej Wieczór-Retman
2025-12-05 13:54 ` Andrey Konovalov
2025-12-04 22:21 ` [PATCH v3 0/3] kasan: vmalloc: Fixes for the percpu allocator and vrealloc Andrew Morton
2025-12-05 7:57 ` Maciej Wieczór-Retman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1764874575.git.m.wieczorretman@pm.me \
--to=m.wieczorretman@pm.me \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=dakr@kernel.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=jiayuan.chen@linux.dev \
--cc=kasan-dev@googlegroups.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryabinin.a.a@gmail.com \
--cc=urezki@gmail.com \
--cc=vincenzo.frascino@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox