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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Extension (`freplace`) and tracing (`fentry`/`fexit`) programs attached to `struct_ops` programs with `__arena` arguments bypass type safety, treating user-controlled 32-bit arena offsets as trusted kernel pointers (`PTR_TO_BTF_ID`).
--

--- Patch [5]: [PATCH bpf-next v4 05/13] bpf: Support __arena and __arena__nullable on struct_ops arguments ---
(Note: The formatting of this report is altered due to system recitation restrictions. I am providing a free-form summary of the findings rather than quoting the original code inline.)

commit fe44e46765df675218e6d1c19ad3b275b47f1966
Author: Tejun Heo <tj@kernel.org>
Subject: bpf: Support __arena and __arena__nullable on struct_ops arguments

This patch adds support for __arena and __arena__nullable suffixes on BPF
struct_ops arguments. It allows passing arena pointers directly to struct_ops
callbacks by converting kernel addresses to arena offsets in the trampoline
context array.

[Severity: Critical]
Does this allow extension (freplace) and tracing (fentry/fexit) programs to
bypass type safety when attaching to struct_ops programs that use __arena
arguments?

In kernel/bpf/btf.c:btf_ctx_access(), the verifier iterates over
prog->aux->ctx_arg_info_size to enforce PTR_TO_ARENA. However, for extension
and tracing programs, ctx_arg_info_size is 0. This causes the verifier to skip
the arena type check and fall through, incorrectly typing the argument as a
trusted kernel pointer (PTR_TO_BTF_ID) via the target program translation.

During attachment in kernel/bpf/trampoline.c:__bpf_trampoline_link_prog(),
the safeguard calls bpf_prog_has_arena_ctx_arg(node->link->prog) on the
attaching program instead of the target program. Because the attaching program
lacks ctx_arg_info, this check returns false and allows the unsafe attachment
to proceed.

At runtime, the struct_ops trampoline converts the kernel pointer to a 32-bit
arena offset in the context array. Since the extension or tracing program was
verified believing this argument is a PTR_TO_BTF_ID, could this allow it to
dereference a user-controlled 32-bit arena offset as a trusted kernel pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805210427.3218326-1-memxor@gmail.com?part=5