linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Maciej Żenczykowski" <maze@google.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Andrey Konovalov" <andreyknvl@gmail.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	kasan-dev@googlegroups.com, "Uladzislau Rezki" <urezki@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	joonki.min@samsung-slsi.corp-partner.google.com,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/kasan: Fix KASAN poisoning in vrealloc()
Date: Wed, 14 Jan 2026 12:17:13 +0000	[thread overview]
Message-ID: <aWd2wquw1aEB2rON@wieczorr-mobl1.localdomain> (raw)
In-Reply-To: <20260113191516.31015-1-ryabinin.a.a@gmail.com>

Tested in generic and sw_tags modes. Compiles and runs okay with and without my
KASAN sw tags patches on x86. Kunit tests also seem fine.

Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

On 2026-01-13 at 20:15:15 +0100, Andrey Ryabinin wrote:
>A KASAN warning can be triggered when vrealloc() changes the requested
>size to a value that is not aligned to KASAN_GRANULE_SIZE.
>
>    ------------[ cut here ]------------
>    WARNING: CPU: 2 PID: 1 at mm/kasan/shadow.c:174 kasan_unpoison+0x40/0x48
>    ...
>    pc : kasan_unpoison+0x40/0x48
>    lr : __kasan_unpoison_vmalloc+0x40/0x68
>    Call trace:
>     kasan_unpoison+0x40/0x48 (P)
>     vrealloc_node_align_noprof+0x200/0x320
>     bpf_patch_insn_data+0x90/0x2f0
>     convert_ctx_accesses+0x8c0/0x1158
>     bpf_check+0x1488/0x1900
>     bpf_prog_load+0xd20/0x1258
>     __sys_bpf+0x96c/0xdf0
>     __arm64_sys_bpf+0x50/0xa0
>     invoke_syscall+0x90/0x160
>
>Introduce a dedicated kasan_vrealloc() helper that centralizes
>KASAN handling for vmalloc reallocations. The helper accounts for KASAN
>granule alignment when growing or shrinking an allocation and ensures
>that partial granules are handled correctly.
>
>Use this helper from vrealloc_node_align_noprof() to fix poisoning
>logic.
>
>Reported-by: Maciej Żenczykowski <maze@google.com>
>Reported-by: <joonki.min@samsung-slsi.corp-partner.google.com>
>Closes: https://lkml.kernel.org/r/CANP3RGeuRW53vukDy7WDO3FiVgu34-xVJYkfpm08oLO3odYFrA@mail.gmail.com
>Fixes: d699440f58ce ("mm: fix vrealloc()'s KASAN poisoning logic")
>Cc: stable@vger.kernel.org
>Signed-off-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
>---
> include/linux/kasan.h |  6 ++++++
> mm/kasan/shadow.c     | 24 ++++++++++++++++++++++++
> mm/vmalloc.c          |  7 ++-----
> 3 files changed, 32 insertions(+), 5 deletions(-)
>
>diff --git a/include/linux/kasan.h b/include/linux/kasan.h
>index 9c6ac4b62eb9..ff27712dd3c8 100644
>--- a/include/linux/kasan.h
>+++ b/include/linux/kasan.h
>@@ -641,6 +641,9 @@ kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> 		__kasan_unpoison_vmap_areas(vms, nr_vms, flags);
> }
> 
>+void kasan_vrealloc(const void *start, unsigned long old_size,
>+		unsigned long new_size);
>+
> #else /* CONFIG_KASAN_VMALLOC */
> 
> static inline void kasan_populate_early_vm_area_shadow(void *start,
>@@ -670,6 +673,9 @@ kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
> 			  kasan_vmalloc_flags_t flags)
> { }
> 
>+static inline void kasan_vrealloc(const void *start, unsigned long old_size,
>+				unsigned long new_size) { }
>+
> #endif /* CONFIG_KASAN_VMALLOC */
> 
> #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
>diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
>index 32fbdf759ea2..e9b6b2d8e651 100644
>--- a/mm/kasan/shadow.c
>+++ b/mm/kasan/shadow.c
>@@ -651,6 +651,30 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size)
> 	kasan_poison(start, size, KASAN_VMALLOC_INVALID, false);
> }
> 
>+void kasan_vrealloc(const void *addr, unsigned long old_size,
>+		unsigned long new_size)
>+{
>+	if (!kasan_enabled())
>+		return;
>+
>+	if (new_size < old_size) {
>+		kasan_poison_last_granule(addr, new_size);
>+
>+		new_size = round_up(new_size, KASAN_GRANULE_SIZE);
>+		old_size = round_up(old_size, KASAN_GRANULE_SIZE);
>+		if (new_size < old_size)
>+			__kasan_poison_vmalloc(addr + new_size,
>+					old_size - new_size);
>+	} else if (new_size > old_size) {
>+		old_size = round_down(old_size, KASAN_GRANULE_SIZE);
>+		__kasan_unpoison_vmalloc(addr + old_size,
>+					new_size - old_size,
>+					KASAN_VMALLOC_PROT_NORMAL |
>+					KASAN_VMALLOC_VM_ALLOC |
>+					KASAN_VMALLOC_KEEP_TAG);
>+	}
>+}
>+
> #else /* CONFIG_KASAN_VMALLOC */
> 
> int kasan_alloc_module_shadow(void *addr, size_t size, gfp_t gfp_mask)
>diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>index 41dd01e8430c..2536d34df058 100644
>--- a/mm/vmalloc.c
>+++ b/mm/vmalloc.c
>@@ -4322,7 +4322,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> 		if (want_init_on_free() || want_init_on_alloc(flags))
> 			memset((void *)p + size, 0, old_size - size);
> 		vm->requested_size = size;
>-		kasan_poison_vmalloc(p + size, old_size - size);
>+		kasan_vrealloc(p, old_size, size);
> 		return (void *)p;
> 	}
> 
>@@ -4330,16 +4330,13 @@ 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_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
> 		 * realloc shrink time.
> 		 */
> 		vm->requested_size = size;
>+		kasan_vrealloc(p, old_size, size);
> 		return (void *)p;
> 	}
> 
>-- 
>2.52.0
>

-- 
Kind regards
Maciej Wieczór-Retman



      parent reply	other threads:[~2026-01-14 12:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-06 12:42 KASAN vs realloc Maciej Żenczykowski
2026-01-07 20:28 ` Kees Cook
2026-01-07 20:47   ` Maciej Wieczor-Retman
2026-01-07 21:47     ` Maciej Żenczykowski
2026-01-07 21:50       ` Maciej Żenczykowski
2026-01-07 21:55         ` Maciej Żenczykowski
2026-01-09 18:55           ` Maciej Wieczor-Retman
2026-01-09 20:05             ` Maciej Żenczykowski
2026-01-13 19:15 ` [PATCH 1/2] mm/kasan: Fix KASAN poisoning in vrealloc() Andrey Ryabinin
2026-01-13 19:15   ` [PATCH 2/2] mm/kasan/kunit: extend vmalloc OOB tests to cover vrealloc() Andrey Ryabinin
2026-01-14 12:17   ` Maciej Wieczor-Retman [this message]

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=aWd2wquw1aEB2rON@wieczorr-mobl1.localdomain \
    --to=m.wieczorretman@pm.me \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=joonki.min@samsung-slsi.corp-partner.google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maze@google.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=stable@vger.kernel.org \
    --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