Re: [PATCH bpf-next v4 11/25] bpf: Reject stack arguments in non-JITed programs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The patch fails to prevent interpreter fallback if stack arguments are used only in nested subprograms (e.g., Main -> Subprog A -> Subprog B). This can lead to a kernel crash via an uninitialized R11 dereference.
- [Low] Standalone global functions with stack arguments are rejected with `-ENOTSUPP` without a verifier log, instead of `-EINVAL` with a descriptive message.
--

commit 851a484e2b5b68983f11bc3764118f2bcba5acb0
Author: Yonghong Song <yonghong.song@linux.dev>

bpf: Reject stack arguments in non-JITed programs

This patch attempts to reject programs that use stack arguments when running in
the interpreter, as the interpreter does not support the BPF_REG_PARAMS (r11)
register. It does this by checking for stack arguments in
__bpf_prog_select_runtime() and bpf_fixup_call_args().

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index ae10b9ca018df..958d86f0beac3 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -2599,7 +2599,7 @@ struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct
>  		goto finalize;
>  
>  	if (IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) ||
> -	    bpf_prog_has_kfunc_call(fp))
> +	    bpf_prog_has_kfunc_call(fp) || (env && env->subprog_info[0].stack_arg_cnt))
>  		jit_needed = true;

Does this condition correctly catch stack arguments in nested subprograms?

env->subprog_info[0].stack_arg_cnt only tracks the main program's incoming
and direct outgoing stack arguments. If the main program calls Subprog A with
no stack arguments, and Subprog A calls Subprog B with more than 5 arguments,
the main program's stack_arg_cnt remains 0.

If bpf_prog_jit_compile() subsequently fails for the main program,
jit_needed evaluates to false and it falls back to the interpreter.

>  
>  	if (!bpf_prog_select_interpreter(fp))
> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
> index ba86039789fdf..19056016eed8b 100644
> --- a/kernel/bpf/fixups.c
> +++ b/kernel/bpf/fixups.c
> @@ -1407,6 +1407,12 @@ int bpf_fixup_call_args(struct bpf_verifier_env *env)
>  		verbose(env, "calling kernel functions are not allowed in non-JITed programs\n");
>  		return -EINVAL;
>  	}

Is it possible for bpf_jit_subprogs() to succeed earlier in this function
and return 0, bypassing these new checks entirely?

If jit_requested is true, bpf_jit_subprogs() is called before this
point:

kernel/bpf/fixups.c:bpf_fixup_call_args() {
    ...
	if (env->prog->jit_requested &&
	    !bpf_prog_is_offloaded(env->prog->aux)) {
		err = bpf_jit_subprogs(env);
		if (err == 0)
			return 0;
    ...
}

If it succeeds, the function returns 0 early, skipping the new loop.

Combined with the issue in __bpf_prog_select_runtime() above, the interpreter
could end up executing the main program and processing BPF_PSEUDO_CALL
instructions by jumping to the un-JITted instructions of the subprograms. 

When Subprog A writes to outgoing stack slots via BPF_REG_PARAMS (r11), the
interpreter will use an uninitialized r11, potentially corrupting memory.

> +	for (i = 1; i < env->subprog_cnt; i++) {

Should this loop start at i = 0 to properly handle standalone global
functions?

For standalone global functions that are verified independently,
env->subprog_cnt is 1. Starting the loop at i = 1 skips the global
function entirely.

The program is still safely rejected later in __bpf_prog_select_runtime()
because env->subprog_info[0].stack_arg_cnt > 0 correctly sets
jit_needed = true, leading to an -ENOTSUPP return. However, starting at
i = 0 would emit the expected verifier log and return -EINVAL instead of
failing silently with -ENOTSUPP.

> +		if (bpf_in_stack_arg_cnt(&env->subprog_info[i])) {
> +			verbose(env, "stack args are not supported in non-JITed programs\n");
> +			return -EINVAL;
> +		}
> +	}
>  	if (env->subprog_cnt > 1 && env->prog->aux->tail_call_reachable) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513044949.2382019-1-yonghong.song@linux.dev?part=11