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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] EXT (freplace) and TRACING (fentry/fexit) programs attached to struct_ops programs bypass defensive checks and `ctx_arg_info` inheritance, causing them to incorrectly verify arena pointers as trusted kernel pointers (`PTR_TO_BTF_ID`).
--

--- Patch [2]: [PATCH bpf-next v1 2/9] bpf: Support __arena and __arena_nullable on struct_ops stub arguments ---
commit 592a1abca0acd2ddc98e47619cf772faa71d7c0d
Author: Tejun Heo <tj@kernel.org>

bpf: Support __arena and __arena_nullable on struct_ops stub arguments

This patch adds support for the __arena and __arena_nullable suffixes on
struct_ops callback arguments. The trampoline automatically converts the
kernel pointer to an arena pointer when saving arguments, allowing the BPF
program to dereference it directly.

> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index 6eadf64f7ec90..56759891eab79 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c

[ ... ]

> @@ -688,6 +736,22 @@ static int bpf_trampoline_update(struct bpf_trampoline *tr, bool lock_direct_mut
>  		goto out;
>  	}
>  
> +	/*
> +	 * Arena ctx args are converted only by the struct_ops indirect
> +	 * trampoline, which dispatches to a single known prog. Generic
> +	 * trampolines can mix progs with different arenas, so no conversion
> +	 * is possible here. Not reachable today: only struct_ops progs get
> +	 * arena ctx args and they never ride generic trampolines.
> +	 */
> +	for (kind = 0; kind < BPF_TRAMP_MAX; kind++) {
> +		for (i = 0; i < tnodes[kind].nr_nodes; i++) {
> +			if (bpf_prog_has_arena_ctx_arg(tnodes[kind].nodes[i]->link->prog)) {
> +				err = -ENOTSUPP;
> +				goto out;
> +			}
> +		}
> +	}

[Severity: Critical]
Will this defensive check be bypassed for FENTRY/EXT programs attached to
struct_ops programs?

When an FENTRY or EXT program attaches to a struct_ops program, it does not
inherit ctx_arg_info from its target in bpf_check_attach_target(). Because
the attaching program lacks ctx_arg_info, bpf_prog_has_arena_ctx_arg()
would return false here, allowing the attachment to proceed instead of
returning -ENOTSUPP.

If this check is bypassed, could the attaching FENTRY/EXT program evaluate
the argument as a standard PTR_TO_BTF_ID? Since the generic FENTRY
trampoline receives the already-converted, user-controlled arena offset from
the struct_ops caller, this might allow an attaching program to treat an
untrusted offset as a trusted kernel pointer.

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