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

[email protected]
Newsgroups org.kernel.vger.bpf
Message-ID <[email protected]>
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 <[email protected]>
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/[email protected]?part=5
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.