linux-kernel - Re: [PATCH v1] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5o7owlr4ap5fridqlkerrnuvwwlgldr35gvkcf6df4fufatrr6@yn5rmfn54i62>
Date: Thu, 04 Dec 2025 13:55:09 +0000
From: Maciej Wieczor-Retman <m.wieczorretman@...me>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>, linux-mm@...ck.org, syzbot+997752115a851cb0cf36@...kaller.appspotmail.com, Andrey Ryabinin <ryabinin.a.a@...il.com>, Alexander Potapenko <glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>, Andrew Morton <akpm@...ux-foundation.org>, Uladzislau Rezki <urezki@...il.com>, Danilo Krummrich <dakr@...nel.org>, Kees Cook <kees@...nel.org>, kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN

On 2025-12-03 at 02:05:11 +0000, Jiayuan Chen wrote:
>December 3, 2025 at 04:48, "Maciej Wieczor-Retman" <maciej.wieczor-retman@...el.com mailto:maciej.wieczor-retman@...el.com?to=%22Maciej%20Wieczor-Retman%22%20%3Cmaciej.wieczor-retman%40intel.com%3E > wrote:
>> 
>> Hi, I'm working on [1]. As Andrew pointed out to me the patches are quite
>> similar. I was wondering if you mind if the reuse_tag was an actual tag value?
>> Instead of just bool toggling the usage of kasan_random_tag()?
>> 
>> I tested the problem I'm seeing, with your patch and the tags end up being reset.
>> That's because the vms[area] pointers that I want to unpoison don't have a tag
>> set, but generating a different random tag for each vms[] pointer crashes the
>> kernel down the line. So __kasan_unpoison_vmalloc() needs to be called on each
>> one but with the same tag.
>> 
>> Arguably I noticed my series also just resets the tags right now, but I'm
>> working to correct it at the moment. I can send a fixed version tomorrow. Just
>> wanted to ask if having __kasan_unpoison_vmalloc() set an actual predefined tag
>> is a problem from your point of view?
>> 
>> [1] https://lore.kernel.org/all/cover.1764685296.git.m.wieczorretman@pm.me/
>> 
>
>Hi Maciej,
>
>It seems we're focusing on different issues, but feel free to reuse or modify the 'reuse_tag'.
>It's intended to preserve the tag in one 'vma'.
>
>I'd also be happy to help reproduce and test your changes to ensure the issue I encountered
>isn't regressed once you send a patch based on mine. 
>
>Thanks.

After reading Andrey's comments on your patches and mine I tried applying all
the changes to test the flag approach. Now my patches don't modify any vrealloc
related code. I came up with something like this below from your patch. Just
tested it and it works fine on my end, does it look okay to you?

---
 include/linux/kasan.h | 1 +
 mm/kasan/hw_tags.c    | 3 ++-
 mm/kasan/shadow.c     | 4 +++-
 mm/vmalloc.c          | 6 ++++--
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 03e263fb9fa1..068f62d07122 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)
 
 #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..e6d7ee544c28 100644
--- a/mm/kasan/hw_tags.c
+++ b/mm/kasan/hw_tags.c
@@ -361,7 +361,8 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
 		return (void *)start;
 	}
 
-	tag = kasan_random_tag();
+	tag = (flags & KASAN_VMALLOC_KEEP_TAG) ? get_tag(start) :
+						 kasan_random_tag();
 	start = set_tag(start, tag);
 
 	/* Unpoison and initialize memory up to size. */
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index 5d2a876035d6..6dd61093d1d5 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size,
 	    !(flags & KASAN_VMALLOC_PROT_NORMAL))
 		return (void *)start;
 
-	start = set_tag(start, kasan_random_tag());
+	if (!(flags & KASAN_VMALLOC_KEEP_TAG))
+		start = 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 ead22a610b18..c939dc04baa5 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4180,8 +4180,10 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
 	 * We already have the bytes available in the allocation; use them.
 	 */
 	if (size <= alloced_size) {
-		kasan_unpoison_vmalloc(p + old_size, size - old_size,
-				       KASAN_VMALLOC_PROT_NORMAL);
+		kasan_unpoison_vmalloc(p, size,
+				       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

-- 
Kind regards
Maciej Wieczór-Retman