From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: catalin.marinas@arm.com, kevin.brodsky@arm.com,
ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
dvyukov@google.com, vincenzo.frascino@arm.com, urezki@gmail.com,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, bpf@vger.kernel.org, stable@vger.kernel.org,
Jiayuan Chen <jiayuan.chen@linux.dev>
Subject: Re: [PATCH] kasan: hw_tags: fix a false positive case of vrealloc in alloced size
Date: Sat, 29 Nov 2025 23:49:14 +0000 [thread overview]
Message-ID: <aSuGeoeLTPSK1L5l@e129823.arm.com> (raw)
In-Reply-To: <aSuBHo7fpQxQYgef@e129823.arm.com>
On Sat, Nov 29, 2025 at 11:26:25PM +0000, Yeoreum Yun wrote:
> Hi Andrew,
>
> > On Sat, 29 Nov 2025 12:36:47 +0000 Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> >
> > > When a memory region is allocated with vmalloc() and later expanded with
> > > vrealloc() — while still within the originally allocated size —
> > > KASAN may report a false positive because
> > > it does not update the tags for the newly expanded portion of the memory.
> > >
> > > A typical example of this pattern occurs in the BPF verifier,
> > > and the following is a related false positive report:
> > >
> > > [ 2206.486476] ==================================================================
> > > [ 2206.486509] BUG: KASAN: invalid-access in __memcpy+0xc/0x30
> > > [ 2206.486607] Write at addr f5ff800083765270 by task test_progs/205
> > > [ 2206.486664] Pointer tag: [f5], memory tag: [fe]
> > > [ 2206.486703]
> > > [ 2206.486745] CPU: 4 UID: 0 PID: 205 Comm: test_progs Tainted: G OE 6.18.0-rc7+ #145 PREEMPT(full)
> > > [ 2206.486861] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> > > [ 2206.486897] Hardware name: , BIOS
> > > [ 2206.486932] Call trace:
> > > [ 2206.486961] show_stack+0x24/0x40 (C)
> > > [ 2206.487071] __dump_stack+0x28/0x48
> > > [ 2206.487182] dump_stack_lvl+0x7c/0xb0
> > > [ 2206.487293] print_address_description+0x80/0x270
> > > [ 2206.487403] print_report+0x94/0x100
> > > [ 2206.487505] kasan_report+0xd8/0x150
> > > [ 2206.487606] __do_kernel_fault+0x64/0x268
> > > [ 2206.487717] do_bad_area+0x38/0x110
> > > [ 2206.487820] do_tag_check_fault+0x38/0x60
> > > [ 2206.487936] do_mem_abort+0x48/0xc8
> > > [ 2206.488042] el1_abort+0x40/0x70
> > > [ 2206.488127] el1h_64_sync_handler+0x50/0x118
> > > [ 2206.488217] el1h_64_sync+0xa4/0xa8
> > > [ 2206.488303] __memcpy+0xc/0x30 (P)
> > > [ 2206.488412] do_misc_fixups+0x4f8/0x1950
> > > [ 2206.488528] bpf_check+0x31c/0x840
> > > [ 2206.488638] bpf_prog_load+0x58c/0x658
> > > [ 2206.488737] __sys_bpf+0x364/0x488
> > > [ 2206.488833] __arm64_sys_bpf+0x30/0x58
> > > [ 2206.488920] invoke_syscall+0x68/0xe8
> > > [ 2206.489033] el0_svc_common+0xb0/0xf8
> > > [ 2206.489143] do_el0_svc+0x28/0x48
> > > [ 2206.489249] el0_svc+0x40/0xe8
> > > [ 2206.489337] el0t_64_sync_handler+0x84/0x140
> > > [ 2206.489427] el0t_64_sync+0x1bc/0x1c0
> > >
> > > Here, 0xf5ff800083765000 is vmalloc()ed address for
> > > env->insn_aux_data with the size of 0x268.
> > > While this region is expanded size by 0x478 and initialise
> > > increased region to apply patched instructions,
> > > a false positive is triggered at the address 0xf5ff800083765270
> > > because __kasan_unpoison_vmalloc() with KASAN_VMALLOC_PROT_NORMAL flag only
> > > doesn't update the tag on increaed region.
> > >
> > > To address this, introduces KASAN_VMALLOC_EXPAND flag which
> > > is used to expand vmalloc()ed memory in range of real allocated size
> > > to update tag for increased region.
> >
> > Thanks.
> >
> > > Fixes: 23689e91fb22 ("kasan, vmalloc: add vmalloc tagging for HW_TAGS”)
> > > Cc: <stable@vger.kernel.org>
> >
> > Unfortunately this is changing the same code as "mm/kasan: fix
> > incorrect unpoisoning in vrealloc for KASAN",
> > (https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev)
> > which is also cc:stable.
> >
> > So could you please take a look at the code in mm.git's
> > mm-hotfixes-unstable branch
> > (git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm) and base the
> > fix upon that? This way everything should merge and backport nicely.
>
> Thanks for sharing this :)
> But I think the patch from Jiayuan still has a problem
> since vrealloc() can pass the "unaligned address" with KASAN_GRANULE_SIZE
> and this will trigger WARN_ON() in kasan_unpoison().
Ah, I missed his patch change the pointer from p + old_size to p
for the kasan_unpoison_vrealloc().
Then the patch seems almost identical to fix the same problem.
So, you can drop my patch.
Sorry to make noise :\
[...]
--
Sincerely,
Yeoreum Yun
prev parent reply other threads:[~2025-11-29 23:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-29 12:36 [PATCH] kasan: hw_tags: fix a false positive case of vrealloc in alloced size Yeoreum Yun
2025-11-29 18:06 ` Andrew Morton
2025-11-29 23:26 ` Yeoreum Yun
2025-11-29 23:49 ` Yeoreum Yun [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=aSuGeoeLTPSK1L5l@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=jiayuan.chen@linux.dev \
--cc=kasan-dev@googlegroups.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.