From nobody Sun Feb 8 02:55:30 2026 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B26492D63F8 for ; Tue, 4 Nov 2025 14:49:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.22 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762267757; cv=none; b=SoA+1NnOm0EYw6XbkVDD7D2wiA1lVXnJn95sBnb/bmQbZFcwcIeHK12GZ/5mUA49YRDcmDfOj+RK/v486lnrzA90JnD+zl2vJX4PvMnR0x42qpaetEmKMMwCecwcofvCgZVlgMWs20My+92tmK46Z1LXV2h0CAYgFAlU0E+vkKQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762267757; c=relaxed/simple; bh=7bvapD1uqsnNYi1Q3JJRh8kAisoWEx0DwRXG2a9BbQQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VpefWynF6Ul32MD3h+6XBSPtvZ7qwcspPPh1QnXgiCBl2LNXcc7ezwRWt3O0ibAd+j2kH7tX7w03zal+ObxEaCCOC++Tct9VbsUbITQPy/kN5IH5Xl2qMM1zVVHRvaA9XfIiS6uYbmWF5INCFqYsWwariN34GZwKcDFWJAY6i08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=sLxtTSkC; arc=none smtp.client-ip=185.70.43.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="sLxtTSkC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1762267753; x=1762526953; bh=xfqs8NGDzi/GLs93yh/ZnyHEZsNbd7BFWZBeJoDbuBw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=sLxtTSkCbLJUhXOFbUAzkkZTsRM3HZRQToyIFBaRu0PGKyO5fKHZRIxLblCnA8aYq 1xoYfY5qfeaDniIW4yU04b5OalIS28PDRxj+azfnN/T1tuuyxwhtvNxmTqubXlVhCP 5Wmk14Q2eC7LgmtAM6XkOP6t9k8j5zagrcZeoLWy3Eae2EIy/LmGPcSjjXKunZHQeT 6DVds+bC8KILEg+9m7m6wV+oKy6hyY+wCp12XaOtqDKrgK/+buG6nEwcCt2Jf1PjPB p+2mjdRnk6A4YqsQfKo4GSIhwGBNCXB6TR/nuFpapEoYpzSN1o6Ve3JeLMfBT0hAo7 YpBYBfB6AI79A== Date: Tue, 04 Nov 2025 14:49:08 +0000 To: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Uladzislau Rezki , Marco Elver From: Maciej Wieczor-Retman Cc: m.wieczorretman@pm.me, stable@vger.kernel.org, Maciej Wieczor-Retman , Baoquan He , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1 1/2] kasan: Unpoison pcpu chunks with base address tag Message-ID: <821677dd824d003cc5b7a77891db4723e23518ea.1762267022.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: fd6efc8602e9b03ae9b37c660c7f86c9a4b17086 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman 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 moving it into a helper in preparation for the actual fix. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: # 6.1+ Signed-off-by: Maciej Wieczor-Retman Tested-by: Baoquan He --- 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. include/linux/kasan.h | 10 ++++++++++ mm/kasan/common.c | 11 +++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..b00849ea8ffd 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -614,6 +614,13 @@ static __always_inline void kasan_poison_vmalloc(const= void *start, __kasan_poison_vmalloc(start, size); } =20 +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms); +static __always_inline void kasan_unpoison_vmap_areas(struct vm_struct **v= ms, int nr_vms) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms); +} + #else /* CONFIG_KASAN_VMALLOC */ =20 static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -638,6 +645,9 @@ static inline void *kasan_unpoison_vmalloc(const void *= start, static inline void kasan_poison_vmalloc(const void *start, unsigned long s= ize) { } =20 +static inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int n= r_vms) +{ } + #endif /* CONFIG_KASAN_VMALLOC */ =20 #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/common.c b/mm/kasan/common.c index d4c14359feaf..c63544a98c24 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -28,6 +28,7 @@ #include #include #include +#include =20 #include "kasan.h" #include "../slab.h" @@ -582,3 +583,13 @@ bool __kasan_check_byte(const void *address, unsigned = long ip) } return true; } + +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ + int area; + + for (area =3D 0 ; area < nr_vms ; area++) { + kasan_poison(vms[area]->addr, vms[area]->size, + arch_kasan_get_tag(vms[area]->addr), false); + } +} diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..934c8bfbcebf 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4870,9 +4870,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned l= ong *offsets, * With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ - for (area =3D 0; area < nr_vms; area++) - vms[area]->addr =3D kasan_unpoison_vmalloc(vms[area]->addr, - vms[area]->size, KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vmap_areas(vms, nr_vms); =20 kfree(vas); return vms; --=20 2.51.0 From nobody Sun Feb 8 02:55:30 2026 Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97BCB31B117; Tue, 4 Nov 2025 14:49:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762267800; cv=none; b=sRgSzTomA2ZBCbyi12EfXNBUFxVQHNyaNJcbMnmRC6OKbk7giHfgIsZL9jO/sXm6U7HUYV5+lPzkFifj1b2XJB7nadWENAIwo+mE+85D2nfoEo6ENj3HbFg10cSog/KKsVN6RFYonD2QpRf8VOpVF3h1YmARAo+2tlOQDSwBxus= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762267800; c=relaxed/simple; bh=jPyOeNlQgUZZisQjlGeiGfEr956dNifO7C2Q2JmeBgI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dM5C21HCX67b7pkSjr3+OFkl6C+B3XH2vORX/V/RUPkdlz1hZDbkwwfZ15rH/ENgNZ/6jROhlJz64QCY+MgRw60DfdZZ7K4KiDtCKuf8TAjRNn77klZBQNxpCMqwF82lkuB1f8C+mLywo/4wVqScTA7fH7leWIW4H2vkEPxjoJQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=Q45ZqZeY; arc=none smtp.client-ip=109.224.244.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="Q45ZqZeY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1762267790; x=1762526990; bh=6toufJLKljGqaHG5WZqQpO38Yv3Ls2e+KAx9dPrtmiw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Q45ZqZeYIfexXEzPHWV37QQFzHBmhcuTm8m95wIVxjojEDFnCiwaBpmE4GfVtQpIG Xv+yKdzj99Vix3uQc3UtOqhz0NSwhIIm96fewaISwkdgNrC8SGUAqz5Mu1NqmwqJqB dCQe+XFuWcws2LHUcgn/Lf3r+FckwwwnuuSSJGpJoC0MUnw58rxw/syptWo5sJDVx+ tYVn2zN+Gn5L9UnDqHa1hPX9ZqgpL+2U8Qm5+MaR8w1aLLYp8onv/IKmigRlkS/6Oq rLG8qtXFMv9PbZKAMIAh9mJQnCYRk9WQusCfXFE5Bh7s53iuerfhX3vx6OpeWf0WEP vT0fOHegElP4Q== Date: Tue, 04 Nov 2025 14:49:48 +0000 To: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Marco Elver From: Maciej Wieczor-Retman Cc: m.wieczorretman@pm.me, stable@vger.kernel.org, Maciej Wieczor-Retman , Baoquan He , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v1 2/2] kasan: Unpoison vms[area] addresses with a common tag Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 55cd5ebacaac83958431436550ff0c47705cb95d Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman 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. Unpoison all vm_structs after allocating them for the percpu allocator. Use the same tag to resolve the pcpu chunk address mismatch. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: # 6.1+ Signed-off-by: Maciej Wieczor-Retman Tested-by: Baoquan He --- Changelog v1 (after splitting of from the KASAN series): - 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 | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/kasan/common.c b/mm/kasan/common.c index c63544a98c24..a6bbc68984cd 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -584,12 +584,20 @@ bool __kasan_check_byte(const void *address, unsigned= long ip) return true; } =20 +/* + * A tag mismatch happens when calculating per-cpu chunk addresses, because + * they all inherit the tag from vms[0]->addr, even when nr_vms is bigger + * than 1. This is a problem because all the vms[]->addr come from separate + * allocations and have different tags so while the calculated address is + * correct the tag isn't. + */ void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) { int area; =20 for (area =3D 0 ; area < nr_vms ; area++) { kasan_poison(vms[area]->addr, vms[area]->size, - arch_kasan_get_tag(vms[area]->addr), false); + arch_kasan_get_tag(vms[0]->addr), false); + arch_kasan_set_tag(vms[area]->addr, arch_kasan_get_tag(vms[0]->addr)); } } --=20 2.51.0