From nobody Fri Dec 19 14:44:44 2025 Received: from mail-244116.protonmail.ch (mail-244116.protonmail.ch [109.224.244.116]) (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 3B47A329C74 for ; Fri, 5 Dec 2025 14:59:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.116 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764946803; cv=none; b=jwWENAgRfBonZHbdV1IdCsuRN5FNEOrdFtVAWGgB99Dlq8YEJNOZJusOcCYdH4u9qaDMdB/X1SMxlOwQ2kxy18bf8VGNeSaPHqWkCkGBhcHFRiVW0NHC/MlbxEm0KWcXMLy7fk39WFd+RRu2D1GY95TNRNsNxYa6k4ka5q4ObjI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764946803; c=relaxed/simple; bh=0/02Urwl1R2UcfOuwmOptN271hcNqvgGoytef+jUIJo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hEVjjF4Rpi5pBDwRxxAvHNylFdKoVBsQ77Db2Tjlkhvom1P7lJBRSTUiOH0X3oicjHv9J7BZa1cVEKZqaXkFjOm1F6oUhVyWYNMlEQk2anRk9Aoz1SV0RNnubVs3gOMSdFfDQkGdvzfYfZVZvDOd8PSGIKOQtB9Dvx+NHIaK0AY= 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=NvvwT+Xl; arc=none smtp.client-ip=109.224.244.116 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="NvvwT+Xl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1764946785; x=1765205985; bh=/FxBYSqiLvEPPLBRet/OeAbti72yHyHumcmcCrArpUM=; 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=NvvwT+XlqjIGjbPn28ArTuGmb2NZ/bH055y0UgAlc9MgwM3Qjhw8v4wRgOCWSF3FE xxDf6vS2oJ4EbuZitnh1UD1SJBFGDVFKAamJBHAnPCYB1C8NEixS0HVlu7UdzQZYux hQoL1eTYixZfwrAG9yrJN5uJZWcvEF12qKSsvMo2e3fj6LkO9kXw7A5V4ftW64J1Zq 5caW8XihbSl4/zFsDaes5KKg33S9eU/uo35Ys2Cp5vOY90g5seYNCtBGvAjbWJd70V STfedzSroYtFp9F3B3FS8yTldpm2mEy72sSSZjWrz+yAcFJltECbtD5sARdWu8QIMw LUM4XzJtpdkqA== Date: Fri, 05 Dec 2025 14:59:05 +0000 To: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Uladzislau Rezki , Kees Cook , Danilo Krummrich From: Maciej Wieczor-Retman Cc: jiayuan.chen@linux.dev, m.wieczorretman@pm.me, stable@vger.kernel.org, syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com, Maciej Wieczor-Retman , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v4 1/3] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN Message-ID: <247fd641cbf4a8e6c8135051772867f6bd2610ad.1764945396.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: d2dc6589d37d0aba1e593ab762db40d7e36c2a38 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: Jiayuan Chen Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two issues: 1. In vrealloc the KASAN_VMALLOC_VM_ALLOC flag is missing when unpoisoning the extended region. This flag is required to correctly associate the allocation with KASAN's vmalloc tracking. Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it. vrealloc must behave consistently =E2=80=94 especially when reusing exis= ting vmalloc regions =E2=80=94 to ensure KASAN can track allocations correctl= y. 2. When vrealloc reuses an existing vmalloc region (without allocating new pages) KASAN generates a new tag, which breaks tag-based memory access tracking. Introduce KASAN_VMALLOC_KEEP_TAG, a new KASAN flag that allows reusing the tag already attached to the pointer, ensuring consistent tag behavior during reallocation. Pass KASAN_VMALLOC_KEEP_TAG and KASAN_VMALLOC_VM_ALLOC to the kasan_unpoison_vmalloc inside vrealloc_node_align_noprof(). [1]: https://syzkaller.appspot.com/bug?extid=3D997752115a851cb0cf36 Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Cc: Reported-by: syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@googl= e.com/T/ Signed-off-by: Jiayuan Chen Co-developed-by: Maciej Wieczor-Retman Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Andrey Konovalov --- include/linux/kasan.h | 1 + mm/kasan/hw_tags.c | 2 +- mm/kasan/shadow.c | 4 +++- mm/vmalloc.c | 4 +++- 4 files changed, 8 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..6d7972bb390c 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t; #define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u) #define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u) #define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u) +#define KASAN_VMALLOC_KEEP_TAG ((__force kasan_vmalloc_flags_t)0x08u) =20 #define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply exsiting page range */ #define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */ diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c index 1c373cc4b3fa..cbef5e450954 100644 --- a/mm/kasan/hw_tags.c +++ b/mm/kasan/hw_tags.c @@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const void *start, unsig= ned long size, return (void *)start; } =20 - tag =3D kasan_random_tag(); + tag =3D (flags & KASAN_VMALLOC_KEEP_TAG) ? get_tag(start) : kasan_random_= tag(); start =3D set_tag(start, tag); =20 /* Unpoison and initialize memory up to size. */ diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c index 5d2a876035d6..5e47ae7fdd59 100644 --- a/mm/kasan/shadow.c +++ b/mm/kasan/shadow.c @@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const void *start, unsig= ned long size, !(flags & KASAN_VMALLOC_PROT_NORMAL)) return (void *)start; =20 - start =3D set_tag(start, kasan_random_tag()); + if (unlikely(!(flags & KASAN_VMALLOC_KEEP_TAG))) + start =3D set_tag(start, kasan_random_tag()); + kasan_unpoison(start, size, false); return (void *)start; } diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..22a73a087135 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4176,7 +4176,9 @@ void *vrealloc_node_align_noprof(const void *p, size_= t size, unsigned long align */ if (size <=3D alloced_size) { kasan_unpoison_vmalloc(p + old_size, size - old_size, - KASAN_VMALLOC_PROT_NORMAL); + KASAN_VMALLOC_PROT_NORMAL | + KASAN_VMALLOC_VM_ALLOC | + KASAN_VMALLOC_KEEP_TAG); /* * No need to zero memory here, as unused memory will have * already been zeroed at initial allocation time or during --=20 2.52.0 From nobody Fri Dec 19 14:44:44 2025 Received: from mail-244116.protonmail.ch (mail-244116.protonmail.ch [109.224.244.116]) (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 14A7133A71D for ; Fri, 5 Dec 2025 14:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.116 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764946797; cv=none; b=aPFQdobW8MjleYVtDvYPlR3Y/adTsiQk0S+ixClrnkarSvgpZCmOWgydZq1oBvzjC9PD8/dIn8CU9iT2AUK9sDvx+oLNgtmX6HlQdkGHBqJSUxkfiKZIQ3jeN3nN4w+hEpRgmyjU7Td5bO+2Jwalw41KAC6S9RMIHnfS58wFJaA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764946797; c=relaxed/simple; bh=rPqFBGoEOYKVDFdJQgymk3wZJ11qBG9RpIIfItAPJcU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=I6YlGWYVTg0mnoZiy/URQaaqNcGUdRC+4b8mw1DGum8oUIA5A4z4dc3qGR0bXIeqgUkpzFDWxRZS+mWewf2zqILrYXDdYrqJjjJJ0ac2gSEdRLDW+rZ5ce6nz+Cv0QqP26Lgp38NGONC/pQKBOSLQO9WhPRPL+EH+N47u96QeMY= 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=ZOWGS/m8; arc=none smtp.client-ip=109.224.244.116 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="ZOWGS/m8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1764946784; x=1765205984; bh=qIyabYfRYXeVwZVp9LPPfWirGseEPkYszpblk/XZ5Dw=; 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=ZOWGS/m8tzXkiQ5rMpz2nfSazNtDRqiAV7taCW/XZHvZinRh0fuzw1xalMJyHG1ab NmmS8SF6qxmpWheZnvotMSLFiKUAd6yB7OkYE4RINBY50RpB3Jni5l6u6ztRjB5TuB 5MugaFAEwCTF3DX1z800bHR88KfVIs0venVyLJnnKESz6+oIoxGVkyzuUgnWk1aAj3 Dodl/LWeB2nlQwDFotSW08UdY0skGH/FgEbdT/rtmxXXUyWdlpTwLTtx2WEC+1eqW1 VyE2NqB0hE9sZwNkvYPvhe/tk3WFgas7LfcQAvvuytTAoczZXR+1Cvxj3pOaKfz5xf DeOLp3gaajH0w== Date: Fri, 05 Dec 2025 14:59:17 +0000 To: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Uladzislau Rezki , Marco Elver From: Maciej Wieczor-Retman Cc: jiayuan.chen@linux.dev, m.wieczorretman@pm.me, stable@vger.kernel.org, Maciej Wieczor-Retman , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v4 2/3] kasan: Refactor pcpu kasan vmalloc unpoison Message-ID: <6dd6a10f94241cef935fec58c312cb846d352490.1764945396.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 948f454a99eeea8eab949328f562c02766404396 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 reusing __kasan_unpoison_vmalloc in a new helper in preparation for the actual fix. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Andrey Konovalov --- 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. Changelog v2: - Redo the whole patch so it's an actual refactor. Changelog v3: - Redo the patch after applying Andrey's comments to align the code more with what's already in include/linux/kasan.h include/linux/kasan.h | 15 +++++++++++++++ mm/kasan/common.c | 17 +++++++++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 6d7972bb390c..cde493cb7702 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -615,6 +615,16 @@ 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, + kasan_vmalloc_flags_t flags); +static __always_inline void +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms, flags); +} + #else /* CONFIG_KASAN_VMALLOC */ =20 static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -639,6 +649,11 @@ static inline void *kasan_unpoison_vmalloc(const void = *start, static inline void kasan_poison_vmalloc(const void *start, unsigned long s= ize) { } =20 +static __always_inline void +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ } + #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..1ed6289d471a 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,19 @@ bool __kasan_check_byte(const void *address, unsigned = long ip) } return true; } + +#ifdef CONFIG_KASAN_VMALLOC +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ + unsigned long size; + void *addr; + int area; + + for (area =3D 0 ; area < nr_vms ; area++) { + size =3D vms[area]->size; + addr =3D vms[area]->addr; + vms[area]->addr =3D __kasan_unpoison_vmalloc(addr, size, flags); + } +} +#endif diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 22a73a087135..33e705ccafba 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4872,9 +4872,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, KASAN_VMALLOC_PROT_NORMAL); =20 kfree(vas); return vms; --=20 2.52.0 From nobody Fri Dec 19 14:44:44 2025 Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (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 70E4E33ADA5; Fri, 5 Dec 2025 15:00:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764946810; cv=none; b=CUX2xXfyRFJmk2EynMqg4KHF7nJvGAeyVpjXEzeKj5aCGn2VfJJvKcku78tC3hbSOGj/gTf84PzrjRbSV6tN5mj3dv6AtafeREFSGf5suCRQEX9l76t3PYsRiY+AK1VZ4G4c1db+hgs19I1xgxFjgqoLDnLdlcY7XAVG1OihAgg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764946810; c=relaxed/simple; bh=BTYlCktS5S4g7Exg0JxgMp8sNaVVb77iH5bFN/oFR3A=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DmXkwj88xtXNh/VjanVJCqiD2wHXZPs88g6eTXkJIbNFcOs1vlpqD/+y32sRD8FivqxMQ/I+OW4YOuD1UkmbTP62FQonjGYeKsxBu/JNFCV75iv5NjKiXjzQ/uQsbqdIHJjBym/LiMbQpHJbILP0GWsGpsevMVtu0cLKc6rFshE= 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=N+3AZIRl; arc=none smtp.client-ip=109.224.244.17 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="N+3AZIRl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1764946798; x=1765205998; bh=L0KdqaoEvJRt9/c4L5Rt4JS2SHbqfjLO2UUM/bE4AmE=; 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=N+3AZIRlFffP95lEsDGcJwonEwcbmnmiP+y9G7XIZ4CFhPqE12ntUM7VqVh8YDUHr 6BJW7IfSW9jwX6j3p+t5RY5+0ZEg+L6wKYKw9NKULxp3VFb2cXmz604zMCbYqwA+V5 Uc/Y4JAt9Qklgc14X5IqwNYWQwjAAI3CipzqUjHEO/4J1FgCRc4nrGXFgX7anR/7gF hu++oTotuKns356sfhzGjNvViiiYwVN2nam8yAPQSzrQ7f/kvvB1In/ps2JXOFIcJA 70YVK1WzmHJ9gRvB8H7RqV+iK5AgWStUXVHjnR8fMAeH0ZfefZcy+sv+UVxUM4WgLW Z/OZs+EMukOBg== Date: Fri, 05 Dec 2025 14:59:26 +0000 To: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Marco Elver From: Maciej Wieczor-Retman Cc: jiayuan.chen@linux.dev, m.wieczorretman@pm.me, stable@vger.kernel.org, Maciej Wieczor-Retman , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 3/3] kasan: Unpoison vms[area] addresses with a common tag Message-ID: <919897daaaa3c982a27762a2ee038769ad033991.1764945396.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 1f0ff2af25c0def600917e4f386d03b302b45161 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. 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 Reviewed-by: Andrey Konovalov --- Changelog v4: - Add WARN_ON_ONCE() if the new flag is already set in the helper. (Andrey) - Remove pr_warn() since the comment should be enough. (Andrey) 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 | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/mm/kasan/common.c b/mm/kasan/common.c index 1ed6289d471a..589be3d86735 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -591,11 +591,26 @@ void __kasan_unpoison_vmap_areas(struct vm_struct **v= ms, 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 (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG)) + return; + + size =3D vms[0]->size; + addr =3D vms[0]->addr; + vms[0]->addr =3D __kasan_unpoison_vmalloc(addr, size, flags); + tag =3D get_tag(vms[0]->addr); =20 - for (area =3D 0 ; area < nr_vms ; area++) { + for (area =3D 1 ; area < nr_vms ; area++) { size =3D vms[area]->size; - addr =3D vms[area]->addr; - vms[area]->addr =3D __kasan_unpoison_vmalloc(addr, size, flags); + addr =3D set_tag(vms[area]->addr, tag); + vms[area]->addr =3D + __kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG); } } #endif --=20 2.52.0