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-prev] [day] [month] [year] [list]
Message-ID: <aSuGeoeLTPSK1L5l@e129823.arm.com>
Date: Sat, 29 Nov 2025 23:49:14 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: catalin.marinas@....com, kevin.brodsky@....com, ryabinin.a.a@...il.com,
	glider@...gle.com, andreyknvl@...il.com, dvyukov@...gle.com,
	vincenzo.frascino@....com, urezki@...il.com,
	kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, bpf@...r.kernel.org, stable@...r.kernel.org,
	Jiayuan Chen <jiayuan.chen@...ux.dev>
Subject: Re: [PATCH] kasan: hw_tags: fix a false positive case of vrealloc in
 alloced size

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@....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@...r.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ