Re: [PATCH bpf-next v3 2/9] bpf: Support __arena and __arena_nullable on struct_ops arguments

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `__arena_nullable` BTF parameter suffix is erroneously processed as `__nullable` due to substring matching, breaking `PTR_TO_ARENA` semantics.
- [High] Attaching tracing programs (fentry/fexit) to struct_ops programs with arena arguments causes them to receive 32-bit user-space offsets typed as valid kernel pointers, leading to SMAP violations and kernel panics.
- [Low] Modified multi-line comments do not conform to the required BPF subsystem comment style.
--

--- Patch [2]: [PATCH bpf-next v3 2/9] bpf: Support __arena and __arena_nullable on struct_ops arguments ---
Note: The format of this review has been altered due to system restrictions on
reciting original code. Instead of inline diff quotes, this report provides a
free-form summary of the findings.

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

This patch adds support for the __arena and __arena_nullable suffixes on
struct_ops arguments. This allows callbacks to declare parameters as arena
pointers, while the kernel caller passes the kernel arena address and the
trampoline handles the conversion.

[Severity: High]
In kernel/bpf/bpf_struct_ops.c within prepare_arg_info(), does the if/else
chain incorrectly prioritize the shorter suffix? Because
btf_param_match_suffix() matches the end of the parameter name, a parameter
ending in __arena_nullable also matches the shorter __nullable suffix.

Since the code checks for the nullable condition first, will this cause
__arena_nullable parameters to be incorrectly typed as PTR_MAYBE_NULL and
PTR_TO_BTF_ID rather than PTR_TO_ARENA? This seems like it could cause the
trampoline to skip the arena pointer conversion, passing a raw kernel
pointer instead, and potentially leading to verifier errors if used with a
non-struct pointer.

[Severity: Low]
This isn't a bug, but in kernel/bpf/bpf_struct_ops.c within
prepare_arg_info(), the modified multi-line comments appear to retain the
older kernel comment style where text follows the opening delimiter on the
same line.

Does the BPF subsystem require multi-line comments to have the opening
delimiter on its own line, even when modifying existing comments in a file
that previously used the old style?

[Severity: High]
In kernel/bpf/trampoline.c within bpf_trampoline_update(), does the
defensive check evaluate the wrong program's context arguments? The code
appears to check the attached tracing program (fentry/fexit) for arena
arguments rather than the target struct_ops program.

Since tracing programs do not have their ctx_arg_info initialized, could
this allow them to successfully attach to struct_ops programs that have
arena arguments?

If so, during verification in kernel/bpf/btf.c at btf_ctx_access(), the
tracing program's context argument would be typed as a standard
PTR_TO_BTF_ID because its ctx_arg_info_size is zero. At runtime, the
struct_ops trampoline would convert the kernel pointer to a 32-bit arena
offset, which the tracing program would receive and potentially dereference
as a standard kernel pointer. Could this sequence lead to SMAP violations
and kernel panics?

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