From: "Maciej Żenczykowski" <maze@google.com>
To: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
Cc: Kees Cook <kees@kernel.org>,
joonki.min@samsung-slsi.corp-partner.google.com,
Andrew Morton <akpm@google.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Marco Elver <elver@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>,
Danilo Krummrich <dakr@kernel.org>,
jiayuan.chen@linux.dev,
syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com,
Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
kasan-dev@googlegroups.com,
Kernel hackers <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: KASAN vs realloc
Date: Wed, 7 Jan 2026 22:55:21 +0100 [thread overview]
Message-ID: <CANP3RGcNFgLSgKYPjmro2s1Es04Pnhf+4wHpnSwRX4M8bLDW9g@mail.gmail.com> (raw)
In-Reply-To: <CANP3RGeaEQipgRvk2FedpN54Rrq=fKdLs3PN4_+DThpeqQmTXA@mail.gmail.com>
> 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.
next prev parent reply other threads:[~2026-01-07 21:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-06 12:42 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 [this message]
2026-01-09 18:55 ` Maciej Wieczor-Retman
2026-01-09 20:05 ` Maciej Żenczykowski
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=CANP3RGcNFgLSgKYPjmro2s1Es04Pnhf+4wHpnSwRX4M8bLDW9g@mail.gmail.com \
--to=maze@google.com \
--cc=akpm@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=dakr@kernel.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=jiayuan.chen@linux.dev \
--cc=joonki.min@samsung-slsi.corp-partner.google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.wieczorretman@pm.me \
--cc=maciej.wieczor-retman@intel.com \
--cc=ryabinin.a.a@gmail.com \
--cc=syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com \
--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