From: Yonghong Song <yonghong.song@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 15/25] bpf: Reject stack arguments if tail call reachable
Date: Fri, 15 May 2026 09:39:57 -0700 [thread overview]
Message-ID: <862c4eb6-c1ba-4570-beda-2baaec63d904@linux.dev> (raw)
In-Reply-To: <20260515032335.C4FE4C2BCB0@smtp.kernel.org>
On 5/15/26 5:23 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Order-dependent verification allows invalid programs combining tail calls and stack arguments to bypass checks.
> - [High] Exception and async callbacks bypass the new stack argument and tail call restriction.
> --
>
> commit 807349b213e40b7418c45dc1ae2cee5695bf101d
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Reject stack arguments if tail call reachable
>
> This patch updates the BPF verifier to reject programs that combine tail calls
> with stack arguments, as tail calls are deprecated. It hooks into the call
> depth traversal to fail verification if stack arguments are present in a
> call chain that can reach a tail call.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index a363811aec7a0..47df3f40a71cf 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -5267,14 +5267,23 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,
>> * this info will be utilized by JIT so that we will be preserving the
>> * tail call counter throughout bpf2bpf calls combined with tailcalls
>> */
>> - if (tail_call_reachable)
>> + if (tail_call_reachable) {
>> for (tmp = idx; tmp >= 0; tmp = dinfo[tmp].caller) {
>> if (subprog[tmp].is_exception_cb) {
>> verbose(env, "cannot tail call within exception cb\n");
>> return -EINVAL;
>> }
>> + if (subprog[tmp].stack_arg_cnt) {
> Can this check be bypassed depending on the order of subprogram calls?
No.
>
> If a main program calls subprogram A (which uses stack args) and then
> subprogram B (which has a tail call), it seems subprogram A might be
> evaluated first when tail_call_reachable is false, bypassing this check.
>
> When subprogram B is evaluated, it sets tail_call_reachable to true,
> which propagates to the main program.
>
> When the main program finishes, only the main program's stack_arg_cnt is
> checked, allowing the program to pass verification.
But in this case, main program stack_arg_cnt is not 0, so -EINVAL will return.
> If the calls were reversed, subprogram A would inherit the true state and
> be correctly rejected.
>
> Does this sequence allow invalid programs to bypass the safety check?
>
>> + verbose(env, "tail_calls are not allowed in programs with stack args\n");
>> + return -EINVAL;
>> + }
>> subprog[tmp].tail_call_reachable = true;
>> }
>> + } else if (!idx && subprog[0].has_tail_call && subprog[0].stack_arg_cnt) {
> Does this fallback check miss exception and async callbacks?
This check does not deal with exception and async callbacks.
>
> By explicitly checking !idx and subprog[0], it appears to assume the main
> program is the only call graph root.
>
> Since exception and async callbacks are verified independently as their own
> root programs (where idx > 0), would a callback that contains a tail call,
> uses stack arguments, and makes no BPF-to-BPF calls bypass both the primary
> tail_call_reachable check and this fallback check?
As far as I know, callback and exception prog are not allowing tail call.
For example:
if (subprog[sidx].is_async_cb) {
if (subprog[sidx].has_tail_call) {
verifier_bug(env, "subprog has tail_call and async cb");
return -EFAULT;
}
...
}
...
if (tail_call_reachable) {
for (tmp = idx; tmp >= 0; tmp = dinfo[tmp].caller) {
if (subprog[tmp].is_exception_cb) {
verbose(env, "cannot tail call within exception cb\n");
return -EINVAL;
}
...
}
}
>
>> + verbose(env, "tail_calls are not allowed in programs with stack args\n");
>> + return -EINVAL;
>> + }
>> +
>> if (subprog[0].tail_call_reachable)
>> env->prog->aux->tail_call_reachable = true;
next prev parent reply other threads:[~2026-05-15 16:40 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 4:49 [PATCH bpf-next v4 00/25] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-05-13 4:49 ` [PATCH bpf-next v4 01/25] bpf: Convert bpf_get_spilled_reg macro to static inline function Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 02/25] bpf: Remove copy_register_state wrapper function Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 03/25] bpf: Add helper functions for r11-based stack argument insns Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 04/25] bpf: Set sub->arg_cnt earlier in btf_prepare_func_args() Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 05/25] bpf: Support stack arguments for bpf functions Yonghong Song
2026-05-14 10:46 ` sashiko-bot
2026-05-14 16:07 ` Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 06/25] bpf: Refactor jmp history to use dedicated spi/frame fields Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 07/25] bpf: Add precision marking and backtracking for stack argument slots Yonghong Song
2026-05-13 5:44 ` bot+bpf-ci
2026-05-13 4:50 ` [PATCH bpf-next v4 08/25] bpf: Refactor record_call_access() to extract per-arg logic Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 09/25] bpf: Use arg_is_fp() in has_fp_args() Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 10/25] bpf: Extend liveness analysis to track stack argument slots Yonghong Song
2026-05-13 5:44 ` bot+bpf-ci
2026-05-14 22:53 ` sashiko-bot
2026-05-15 15:29 ` Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 11/25] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-14 23:59 ` sashiko-bot
2026-05-15 16:00 ` Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 12/25] bpf: Prepare architecture JIT support for stack arguments Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-15 0:30 ` sashiko-bot
2026-05-15 16:33 ` Yonghong Song
2026-05-13 4:50 ` [PATCH bpf-next v4 13/25] bpf: Enable r11 based insns Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 14/25] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 15/25] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-15 3:23 ` sashiko-bot
2026-05-15 16:39 ` Yonghong Song [this message]
2026-05-13 4:51 ` [PATCH bpf-next v4 16/25] bpf: Disable private stack for x86_64 if stack arguments used Yonghong Song
2026-05-13 5:33 ` bot+bpf-ci
2026-05-15 5:28 ` sashiko-bot
2026-05-15 16:41 ` Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 17/25] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-05-15 6:02 ` sashiko-bot
2026-05-15 17:55 ` Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 18/25] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-05-15 6:16 ` sashiko-bot
2026-05-15 16:57 ` Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 19/25] selftests/bpf: Add tests for stack argument validation Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 20/25] selftests/bpf: Add BTF fixup for __naked subprog parameter names Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 21/25] selftests/bpf: Add verifier tests for stack argument validation Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 22/25] selftests/bpf: Add precision backtracking test for stack arguments Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 23/25] bpf, arm64: Map BPF_REG_0 to x8 instead of x7 Yonghong Song
2026-05-13 4:51 ` [PATCH bpf-next v4 24/25] bpf, arm64: Add JIT support for stack arguments Yonghong Song
2026-05-15 8:20 ` sashiko-bot
2026-05-15 18:35 ` Yonghong Song
2026-05-13 4:52 ` [PATCH bpf-next v4 25/25] selftests/bpf: Enable stack argument tests for arm64 Yonghong Song
2026-05-13 16:33 ` [PATCH bpf-next v4 00/25] bpf: Support stack arguments for BPF functions and kfuncs Alexei Starovoitov
2026-05-13 17:41 ` Yonghong Song
2026-05-13 17:51 ` Alexei Starovoitov
2026-05-13 18:11 ` Yonghong Song
2026-05-13 16:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=862c4eb6-c1ba-4570-beda-2baaec63d904@linux.dev \
--to=yonghong.song@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox