Re: KASAN vs realloc

["Maciej Żenczykowski" <maze@google.com>]

On Fri, Jan 9, 2026 at 7:55 PM Maciej Wieczor-Retman
<m.wieczorretman@pm.me> wrote:
>
> 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?

I think:
  kasan_poison_vmalloc(round_up(p + size, KASAN_GRANULE_SIZE), old_size - size);
since you round up argument 1, you need to lower argument 2 to match.
Otherwise it can cover an extra granule.

Consider p = granule (16-byte) aligned, size = 1, old_size = 31

Previously (old_size) we had 2 granules (1 byte short), now (size) we
have exactly one (very short one), so we should poison just the 2nd
granule.

This means we need to call poison(p + 16, 16);

--

Perhaps you need to just do something like:
  size_up = round_up(size, GRANULE)
  kasan_poison_vmalloc(p + size_up, old_size - size_up);

this is assuming p is GRANULE aligned.

likely the 2nd argument needs to be rounded up or down.
Possibly one way for poison and the other for unpoison?

You can only poison a granule that is fully covered.  So you need to
round up the start and round down the length.
You need to unpoison even partial granules, so you need to round down
the start and round up the length.

But really you're not rounding lengths, you're rounding the start and
end offsets, and then calculating length as end offset - start offset.

Note though, that I'm not certain.  Perhaps the tail 'fraction' of
granule at the end can actually always be poisoned safely, since no
other alloc could live there anyway.

Maybe this entire logic just needs to round size/old_size up to a
granule size much earlier??

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

--
Maciej Żenczykowski, Kernel Networking Developer @ Google