[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a2d0d37-bcca-454f-85c3-063906ecd042@linux.dev>
Date: Sun, 4 Jan 2026 21:50:04 -0800
From: Yonghong Song <yonghong.song@...ux.dev>
To: Arnaud Lecomte <contact@...aud-lcm.com>,
syzbot+d1b7fa1092def3628bd7@...kaller.appspotmail.com
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
daniel@...earbox.net, eddyz87@...il.com, haoluo@...gle.com,
john.fastabend@...il.com, jolsa@...nel.org, kpsingh@...nel.org,
linux-kernel@...r.kernel.org, martin.lau@...ux.dev, netdev@...r.kernel.org,
sdf@...ichev.me, song@...nel.org, syzkaller-bugs@...glegroups.com,
Brahmajit Das <listout@...tout.xyz>
Subject: Re: [PATCH] bpf-next: Prevent out of bound buffer write in
__bpf_get_stack
On 1/4/26 12:52 PM, Arnaud Lecomte wrote:
> Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stack()
> during stack trace copying.
>
> The issue occurs when: the callchain entry (stored as a per-cpu variable)
> grow between collection and buffer copy, causing it to exceed the initially
> calculated buffer size based on max_depth.
>
> The callchain collection intentionally avoids locking for performance
> reasons, but this creates a window where concurrent modifications can
> occur during the copy operation.
>
> To prevent this from happening, we clamp the trace len to the max
> depth initially calculated with the buffer size and the size of
> a trace.
>
> Reported-by: syzbot+d1b7fa1092def3628bd7@...kaller.appspotmail.com
> Closes: https://lore.kernel.org/all/691231dc.a70a0220.22f260.0101.GAE@google.com/T/
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
> Tested-by: syzbot+d1b7fa1092def3628bd7@...kaller.appspotmail.com
> Cc: Brahmajit Das <listout@...tout.xyz>
> Signed-off-by: Arnaud Lecomte <contact@...aud-lcm.com>
LGTM.
Acked-by: Yonghong Song <yonghong.song@...ux.dev>
Powered by blists - more mailing lists