On Fri, Sep 5, 2025 at 9:48 AM Arnaud lecomte <contact@xxxxxxxxxxxxxx> wrote: > > From: Arnaud Lecomte <contact@xxxxxxxxxxxxxx> > > Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() > when copying stack trace data. The issue occurs when the perf trace > contains more stack entries than the stack map bucket can hold, > leading to an out-of-bounds write in the bucket's data array. > > Reported-by: syzbot+c9b724fbb41cf2538b7b@xxxxxxxxxxxxxxxxxxxxxxxxx > Closes: https://syzkaller.appspot.com/bug?extid=c9b724fbb41cf2538b7b > Fixes: ee2a098851bf ("bpf: Adjust BPF stack helper functions to accommodate skip > 0") > Signed-off-by: Arnaud Lecomte <contact@xxxxxxxxxxxxxx> > Acked-by: Yonghong Song <yonghong.song@xxxxxxxxx> Acked-by: Song Liu <song@xxxxxxxxxx> With one nitpick below. [...] > @@ -390,15 +391,16 @@ BPF_CALL_3(bpf_get_stackid_pe, struct bpf_perf_event_data_kern *, ctx, > return -EFAULT; > > nr_kernel = count_kernel_ip(trace); > + elem_size = stack_map_data_size(map); > + __u64 nr = trace->nr; /* save original */ nit: I think all variable declarations should go to the beginning of the {} block. I am surprised ./scripts/checkpatch.pl doesn't complain this. > > if (kernel) { > - __u64 nr = trace->nr; > - [...]
