Re: [PATCH v2 1/2] bpf: reject stack-argument callback subprograms

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch silently rejects callback subprograms with stack arguments by returning `-EINVAL` without emitting a verifier log message.
--

--- Patch [1]: [PATCH v2 1/2] bpf: reject stack-argument callback subprograms ---
commit 0a06c150da6a5163953fb53d000c974d1e9a97dc
Author: Jérémy Jean <[email protected]>

bpf: reject stack-argument callback subprograms

This commit rejects callback subprograms that declare incoming stack arguments
when processing callback calls. It prevents out-of-bounds reads in callbacks
that attempt to read arguments from the helper's native frame instead of the
synthetic verifier values.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index fdc5fbb1f78ca..5fcefc0eaba00 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -9285,6 +9285,8 @@ static int push_callback_call(struct bpf_verifier_env *env, struct bpf_insn *ins
>  	err = btf_check_subprog_call(env, subprog, caller->regs);
>  	if (err == -EFAULT)
>  		return err;
> +	if (bpf_in_stack_arg_cnt(&env->subprog_info[subprog]))
> +		return -EINVAL;

[Severity: Medium]
Does this silently reject the callback subprogram without providing a verifier
log message? Returning -EINVAL without using verbose() leaves the user with
an opaque error when a BPF program uses a callback subprogram with stack
arguments. Would it be helpful to add a verbose() log here to explain the load
failure to BPF developers?

>  
>  	/* set_callee_state is used for direct subprog calls, but we are
>  	 * interested in validating only BPF helpers that can call subprogs as

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