[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a85e262d-0e04-41d9-9420-56a1ee1aeed5@linux.dev>
Date: Tue, 11 Nov 2025 17:44:45 -0800
From: Yonghong Song <yonghong.song@...ux.dev>
To: Brahmajit Das <listout@...tout.xyz>,
syzbot+d1b7fa1092def3628bd7@...kaller.appspotmail.com
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
contact@...aud-lcm.com, 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
Subject: Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to
fix OOB write
On 11/11/25 12:12 AM, Brahmajit Das wrote:
> syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
> triggered via bpf_get_stack() when capturing a kernel stack trace.
>
> After the recent refactor that introduced stack_map_calculate_max_depth(),
> the code in stack_map_get_build_id_offset() (and related helpers) stopped
> clamping the number of trace entries (`trace_nr`) to the number of elements
> that fit into the stack map value (`num_elem`).
>
> As a result, if the captured stack contained more frames than the map value
> can hold, the subsequent memcpy() would write past the end of the buffer,
> triggering a KASAN report like:
>
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
> Write of size N at addr ... by task syz-executor...
>
> Restore the missing clamp by limiting `trace_nr` to `num_elem` before
> computing the copy length. This mirrors the pre-refactor logic and ensures
> we never copy more bytes than the destination buffer can hold.
>
> No functional change intended beyond reintroducing the missing bound check.
>
> Reported-by: syzbot+d1b7fa1092def3628bd7@...kaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
> Signed-off-by: Brahmajit Das <listout@...tout.xyz>
Acked-by: Yonghong Song <yonghong.song@...ux.dev>
Powered by blists - more mailing lists