linux-kernel - Re: KASAN vs realloc

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWFKEDwwihxGIbQA@wieczorr-mobl1.localdomain>
Date: Fri, 09 Jan 2026 18:55:53 +0000
From: Maciej Wieczor-Retman <m.wieczorretman@...me>
To: Maciej Żenczykowski <maze@...gle.com>
Cc: Kees Cook <kees@...nel.org>, joonki.min@...sung-slsi.corp-partner.google.com, Andrew Morton <akpm@...gle.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>, Marco Elver <elver@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Uladzislau Rezki <urezki@...il.com>, Danilo Krummrich <dakr@...nel.org>, jiayuan.chen@...ux.dev, syzbot+997752115a851cb0cf36@...kaller.appspotmail.com, Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>, kasan-dev@...glegroups.com, Kernel hackers <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: KASAN vs realloc

Okay, so as I understand it, the issue is centered around adding a size to the
pointer - because in that case it can be unaligned and it can trigger warnings.

So what do you think about changing these two:

		kasan_poison_vmalloc(p + size, old_size - size);
		kasan_unpoison_vmalloc(p + old_size, size - old_size,

into something along these lines:

		kasan_poison_vmalloc(round_up(p + size, KASAN_GRANULE_SIZE), old_size - size);
		kasan_unpoison_vmalloc(p + round_down(old_size,	KASAN_GRANULE_SIZE), size - old_size,

>From what I've read in the code the second argument should be rounded_up() at
some point anyway. In the shrinking case we don't want to poison the last
granule of the new reallocated memory chunk so we round_up(size). And in the
enlarging case it would be just as correct to give up on adding anything to the
'p' pointer - but that'd be inefficient since we don't need to KASAN-touch this
memory chunk - so we round_down the lower boundry to get all of the new space in
KASAN aligned chunks.

Did I get it correctly? Or is there some flaw in the logic above?

-- 
Kind regards
Maciej Wieczór-Retman

On 2026-01-07 at 22:55:21 +0100, Maciej Żenczykowski wrote:
>> WARNING: Actually I'm not sure if this is the *right* stack trace.
>> This might be on a bare 6.18 without the latest extra 4 patches.
>> I'm not finding a more recent stack trace.
>
>Found comments from Samsung dev:
>
>But another panic came after those fixes [ie. 4 patches] applied.
>struct bpf_insn_aux_data is 88byte, so panic on warn set when old_size
>ends with 0x8.
>It seems like vrealloc cannot handle that case.
>
>  84.536021] [4:     netbpfload:  771] ------------[ cut here ]------------
>[   84.536196] [4:     netbpfload:  771] WARNING: CPU: 4 PID: 771 at
>mm/kasan/shadow.c:174 __kasan_unpoison_vmalloc+0x94/0xa0
>....
>[   84.773445] [4:     netbpfload:  771] CPU: 4 UID: 0 PID: 771 Comm:
>netbpfload Tainted: G           OE
>6.18.1-android17-0-g41be44edb8d5-4k #1 PREEMPT
>70442b615e7d1d560808f482eb5d71810120225e
>[   84.789323] [4:     netbpfload:  771] Tainted: [O]=OOT_MODULE,
>[E]=UNSIGNED_MODULE
>[   84.795311] [4:     netbpfload:  771] Hardware name: Samsung xxxx
>[   84.802519] [4:     netbpfload:  771] pstate: 03402005 (nzcv daif
>+PAN -UAO +TCO +DIT -SSBS BTYPE=--)
>[   84.810152] [4:     netbpfload:  771] pc : __kasan_unpoison_vmalloc+0x94/0xa0
>[   84.815708] [4:     netbpfload:  771] lr : __kasan_unpoison_vmalloc+0x24/0xa0
>[   84.821264] [4:     netbpfload:  771] sp : ffffffc0a97e77a0
>[   84.825256] [4:     netbpfload:  771] x29: ffffffc0a97e77a0 x28:
>3bffff8837198670 x27: 0000000000008000
>[   84.833069] [4:     netbpfload:  771] x26: 41ffff8837ef8e00 x25:
>ffffffffffffffa8 x24: 00000000000071c8
>[   84.840880] [4:     netbpfload:  771] x23: 0000000000000001 x22:
>00000000ffffffff x21: 000000000000000e
>[   84.848694] [4:     netbpfload:  771] x20: 0000000000000058 x19:
>c3ffffc0a8f271c8 x18: ffffffc082f1c100
>[   84.856504] [4:     netbpfload:  771] x17: 000000003688d116 x16:
>000000003688d116 x15: ffffff8837efff80
>[   84.864317] [4:     netbpfload:  771] x14: 0000000000000180 x13:
>0000000000000000 x12: e6ffff8837eff700
>[   84.872129] [4:     netbpfload:  771] x11: 0000000000000041 x10:
>0000000000000000 x9 : fffffffebf800000
>[   84.879941] [4:     netbpfload:  771] x8 : ffffffc0a8f271c8 x7 :
>0000000000000000 x6 : ffffffc0805bef3c
>[   84.887754] [4:     netbpfload:  771] x5 : 0000000000000000 x4 :
>0000000000000000 x3 : ffffffc080234b6c
>[   84.895566] [4:     netbpfload:  771] x2 : 000000000000000e x1 :
>0000000000000058 x0 : 0000000000000001
>[   84.903377] [4:     netbpfload:  771] Call trace:
>[   84.906502] [4:     netbpfload:  771]  __kasan_unpoison_vmalloc+0x94/0xa0 (P)
>[   84.912058] [4:     netbpfload:  771]  vrealloc_node_align_noprof+0xdc/0x2e4
>[   84.917525] [4:     netbpfload:  771]  bpf_patch_insn_data+0xb0/0x378
>[   84.922384] [4:     netbpfload:  771]  bpf_check+0x25a4/0x8ef0
>[   84.926638] [4:     netbpfload:  771]  bpf_prog_load+0x8dc/0x990
>[   84.931065] [4:     netbpfload:  771]  __sys_bpf+0x340/0x524
>
>[   79.334574][  T827] bpf_patch_insn_data: insn_aux_data size realloc
>at abffffc08ef41000 to 330
>[   79.334919][  T827] bpf_patch_insn_data: insn_aux_data at 55ffffc0a9c00000
>
>[   79.335151][  T827] bpf_patch_insn_data: insn_aux_data size realloc
>at 55ffffc0a9c00000 to 331
>[   79.336331][  T827] vrealloc_node_align_noprof: p=55ffffc0a9c00000
>old_size=7170
>[   79.343898][  T827] vrealloc_node_align_noprof: size=71c8 alloced_size=8000
>[   79.350782][  T827] bpf_patch_insn_data: insn_aux_data at 55ffffc0a9c00000
>
>[   79.357591][  T827] bpf_patch_insn_data: insn_aux_data size realloc
>at 55ffffc0a9c00000 to 332
>[   79.366174][  T827] vrealloc_node_align_noprof: p=55ffffc0a9c00000
>old_size=71c8
>[   79.373588][  T827] vrealloc_node_align_noprof: size=7220 alloced_size=8000
>[   79.380485][  T827] kasan_unpoison: after kasan_reset_tag
>addr=ffffffc0a9c071c8(granule mask=f)
>
>I added 8 bytes dummy data to avoid "p + old_size" was not ended with
>8, it booted well.
>
>diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>index 4c497e839526..f9d3448321e8 100644
>--- a/include/linux/bpf_verifier.h
>+++ b/include/linux/bpf_verifier.h
>@@ -581,6 +581,7 @@ struct bpf_insn_aux_data {
>        u32 scc;
>        /* registers alive before this instruction. */
>        u16 live_regs_before;
>+       u16 buf[4];     // TEST
> };
>
>maze: Likely if 8 bytes worked then 'u8 buf[7]' would too?
>
>it will be 88bytes + 7 bytes = 95 bytes(=0x5f) which is in the range
>of granule mask(=0xf)
>
>I don't think it works, but it works.