Re: [PATCHv5 bpf-next 10/28] bpf: Add multi tracing attach types

[sashiko-bot@kernel.org]

Sashiko AI review found 2 potential issue(s):
- [High] FENTRY_MULTI and FEXIT_MULTI programs can bypass verifier bounds checks and read out-of-bounds kernel stack memory by directly accessing the `ctx` array.
- [High] bpf_multi_func lacks the __used attribute, causing it to be optimized out by Clang LTO, which completely breaks the feature at runtime.
--

Note: The format of this review has been altered due to system recitation
restrictions. Direct quoting of the patch diff has been omitted, and the
findings are provided as a free-form summary.

commit ca84efa8f86b1acb8cf0bd98e80446dbd7c92e12
Author: Jiri Olsa <jolsa@kernel.org>
Subject: bpf: Add multi tracing attach types

This commit introduces new multi-tracing attach types BPF_TRACE_FENTRY_MULTI
and BPF_TRACE_FEXIT_MULTI, along with base verifier support. It uses a dummy
function bpf_multi_func for initial verification before the specific link
attachment happens.

Can this approach lead to out-of-bounds kernel stack memory reads? 

Since the initial verification is done against bpf_multi_func, which is 
defined with 6 arguments, the verifier will statically permit direct context 
accesses up to ctx[5] (and ctx[6] for the return value in FEXIT_MULTI). 
However, when the program is attached to a real function at runtime, the 
trampoline allocates the context array on the kernel stack based on the 
target function's actual argument count. 

If the target function has fewer than 6 arguments, would reading ctx[5] read 
past the allocated context array and leak memory from the caller's stack 
frame? Additionally, would reading ctx[6] for the return value return 
unrelated stack memory instead of the actual return value, since the 
trampoline places the return value dynamically? Does the verifier need to 
explicitly reject direct memory accesses to the context array for these 
program types and enforce the use of bounds-checked helpers like 
bpf_get_func_arg()?

Is it possible for Clang LTO to optimize out the bpf_multi_func function 
entirely? 

The dummy function is defined without a __used or __attribute__((retain)) 
attribute, and the BTF_ID_LIST_GLOBAL_SINGLE macro only embeds the function 
name in an inline assembly section without generating a C-level reference. 
In kernel builds with Link Time Optimization enabled, could the compiler 
eliminate this function as dead code?

If this occurs, pahole would not generate BTF data for it, leaving the BTF 
ID as 0. Would this result in the verifier's bpf_check_attach_target() 
unconditionally rejecting multi-tracing program loads by throwing a missing 
btf_id error? Should a __used attribute be added to the function definition 
to prevent this?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260417192502.194548-11-jolsa@kernel.org?part=1