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

[Yonghong Song <yonghong.song@linux.dev>]

On 5/15/26 1:59 AM, sashiko-bot@kernel.org wrote:
> 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?

I think the above condition '(env && env->subprog_info[0].stack_arg_cnt)' is
unnecessary. This check is for the *main* prog. main prog should not call kfunc,
otherwise jit_needed must be true. helper does not have stack arguments.

If bpf-to-bpf calls are used in this prog, then bpf_fixup_call_args() will
do some checking for all subprogs.

>
> 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.

But if bpf_jit_subprogs() succeed (with more than one subprog), then we will have
            prog->bpf_func = func[0]->bpf_func;

In __bpf_prog_select_runtime(), we have
	   if (fp->bpf_func)
                 goto finalize;
So interpreter will be ignored since jit has done successfully.

>
> 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?

We can do this. Previously I skip 'i = 0' due to

                 if (env->prog->aux->func_info_aux) {
                         ret = btf_prepare_func_args(env, 0);
                         if (ret || sub->arg_cnt != 1 || sub->args[0].arg_type != ARG_PTR_TO_CTX) {
                                 env->prog->aux->func_info_aux[0].unreliable = true;

                 }

since the main prog may have a btf which have more than 5 arguments although
in reality it will have just one argument. If I have i = 0, this will reject
interpreter which is not correct.

Now we have the following change

                 if (env->prog->aux->func_info_aux) {
                         ret = btf_prepare_func_args(env, 0);
                         if (ret || sub->arg_cnt != 1 || sub->args[0].arg_type != ARG_PTR_TO_CTX) {
                                 env->prog->aux->func_info_aux[0].unreliable = true;
                                 sub->arg_cnt = 1;
                                 sub->stack_arg_cnt = 0;
                         }
                 }

So we can safely start from i = 0. Note that i = 0 will definitely
succeed since we have sub->arg_cnt = 1 above. So change to i = 0
won't change anything but can avoid confusion.

>
> 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) {