Skip to content

Conversation

@kernel-patches-daemon-bpf-rc
Copy link

Pull request for series with
subject: bpf: Clamp trace length in __bpf_get_stack to fix OOB write
version: 3
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1021938

@kernel-patches-daemon-bpf-rc
Copy link
Author

Upstream branch: 026bcf9
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1021938
version: 3

@kernel-patches-daemon-bpf-rc
Copy link
Author

Upstream branch: 026bcf9
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1021938
version: 3

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: [email protected]
Fixes: e17d62f ("bpf: Refactor stack map trace depth calculation into helper function")
Signed-off-by: Brahmajit Das <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants