Re: [PATCH bpf-next v5 05/14] bpf: Support __arena and __arena__nullable on struct_ops arguments

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Attaching an extension (freplace) or tracing (FENTRY/FEXIT) program to a struct_ops program with arena arguments bypasses arena context argument verification, leading to type confusion and potential privilege escalation.
--

--- Patch [5]: [PATCH bpf-next v5 05/14] bpf: Support __arena and __arena__nullable on struct_ops arguments ---
commit b8ab49b96186f2dfd00ae0e67ee1912d4b9e3fac
Author: Tejun Heo <[email protected]>
bpf: Support __arena and __arena__nullable on struct_ops arguments

This commit adds support for __arena and __arena__nullable suffixes for
arguments in struct_ops stub functions. It allows callbacks to receive
arena pointers directly, with the trampoline handling the conversion between
the kernel address and the BPF arena pointer.

(Note: The format of this report is altered to use a free-form summary
rather than inline diff quotes due to recitation restrictions.)

[Severity: High]
There appears to be an issue in how __bpf_trampoline_link_prog() checks
for arena arguments when linking programs. The security check evaluates
bpf_prog_has_arena_ctx_arg(node->link->prog), which checks the attaching
program rather than the target program (tgt_prog).

Because the attaching extension or tracing program does not have its
ctx_arg_info_size initialized (it is 0), this check is bypassed and the
attachment is allowed.

Furthermore, during verification of the extension program in
btf_ctx_access(), the verifier loops over ctx_arg_info_size. Since it is
0 for the attaching program, the loop is skipped. The verifier then
incorrectly types the 32-bit offset argument as a trusted 64-bit kernel
pointer (PTR_TO_BTF_ID) based on the original BTF signature.

At runtime, the struct_ops indirect trampoline converts the incoming kernel
pointer into a 32-bit arena offset and invokes the extension program. Since
the verifier sees this as a trusted kernel pointer, could this lead to a
type confusion where a user-controlled 32-bit offset is dereferenced as a
kernel pointer? 

Should __bpf_trampoline_link_prog() check tgt_prog instead, and does the
verifier need to inherit or check the ctx_arg_info of the target program
for extension programs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5