From: Yonghong Song <yonghong.song@linux.dev>
To: sashiko@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 12/17] bpf: Support stack arguments for kfunc calls
Date: Sun, 19 Apr 2026 11:18:19 -0700 [thread overview]
Message-ID: <1e100198-b8df-41a5-a0b1-f22a572def4b@linux.dev> (raw)
In-Reply-To: <20260419170817.D8136C2BCAF@smtp.kernel.org>
On 4/19/26 10:08 AM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 2 potential issue(s):
> - [Critical] Loss of precision tracking for scalar stack arguments due to modifying a local copy (`tmp_reg`).
> - [Critical] Bypassing `mark_chain_precision` for stack arguments breaks data-flow backtracking, enabling unsafe state pruning.
> --
>
> commit 96adcc4832214af51212820f2056565abaf42a32
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Support stack arguments for kfunc calls
>
> Extend the stack argument mechanism to kfunc calls, allowing kfuncs
> with more than 5 parameters to receive additional arguments via the
> r11-based stack arg area.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 2a346e4f28e15..13f1fd7880921 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
> [ ... ]
>> @@ -7314,8 +7322,12 @@ static int check_mem_size_reg(struct bpf_verifier_env *env,
>> }
>> err = check_helper_mem_access(env, mem_reg, mem_argno, size_reg->umax_value,
>> access_type, zero_size_allowed, meta);
>> - if (!err && !is_stack_argno(size_argno))
>> - err = mark_chain_precision(env, size_argno);
>> + if (!err) {
>> + if (is_stack_argno(size_argno))
>> + size_reg->precise = true;
>> + else
>> + err = mark_chain_precision(env, size_argno);
>> + }
>> return err;
>> }
> Does setting size_reg->precise = true without calling mark_chain_precision()
> break data-flow backtracking?
>
> If only the current state's flag is set, parent states and the source
> registers that populated the stack argument will not be marked precise.
> Could this lead to the verifier incorrectly pruning states if execution paths
> merge before the stack store?
You are right. Let me think how to resolve this.
>
> [ ... ]
>> @@ -12373,20 +12400,44 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> [ ... ]
>> if (i < MAX_BPF_FUNC_REG_ARGS) {
>> reg = ®s[i + 1];
>> } else {
>> /* Retrieve the reg state from the outgoing stack arg slot. */
>> struct bpf_func_state *caller = cur_func(env);
>> int spi = out_arg_spi(caller, i - MAX_BPF_FUNC_REG_ARGS);
>>
>> if (!is_stack_arg_slot_initialized(caller, spi)) {
>> verbose(env, "stack %s not properly initialized\n",
>> reg_arg_name(env, argno));
>> return -EINVAL;
>> }
>>
>> tmp_reg = caller->stack_arg_regs[spi];
>> reg = &tmp_reg;
>> regno = -1;
>> }
> [ ... ]
>> @@ -12413,9 +12464,13 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>> reg_arg_name(env, argno));
>> return -EINVAL;
>> }
>> - ret = mark_chain_precision(env, regno);
>> - if (ret < 0)
>> - return ret;
>> + if (regno < 0) {
>> + reg->precise = true;
>> + } else {
>> + ret = mark_chain_precision(env, regno);
>> + if (ret < 0)
>> + return ret;
>> + }
>> meta->arg_constant.found = true;
>> meta->arg_constant.value = reg->var_off.value;
> Does setting reg->precise = true here modify a local copy instead of the actual
> verifier state?
>
> Since reg points to tmp_reg for stack arguments:
>
> tmp_reg = caller->stack_arg_regs[spi];
> reg = &tmp_reg;
>
> it seems that reg->precise = true will only update the block-scoped tmp_reg,
> leaving the real state in caller->stack_arg_regs[spi] untouched. Could this
> cause the verifier to lose track of precision requirements for scalar
> constraints?
Right, tmp_reg is not used. I guess my previous usage of tmp_reg due to
an early hack but I didn't remove it. Will remove tmp_reg in the next revision.
>
> Additionally, similar to check_mem_size_reg() above, bypassing
> mark_chain_precision() for stack arguments appears to skip backtracking
> entirely.
Ack.
next prev parent reply other threads:[~2026-04-19 18:18 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 16:33 [PATCH bpf-next v6 00/17] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 01/17] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 02/17] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 03/17] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-20 23:58 ` Alexei Starovoitov
2026-04-21 4:04 ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 04/17] bpf: Prepare verifier logs for upcoming kfunc stack arguments Yonghong Song
2026-04-21 0:03 ` Alexei Starovoitov
2026-04-21 4:06 ` Yonghong Song
2026-04-21 6:07 ` Yonghong Song
2026-04-21 13:48 ` Alexei Starovoitov
2026-04-21 15:41 ` Yonghong Song
2026-04-21 15:46 ` Alexei Starovoitov
2026-04-21 16:37 ` Yonghong Song
2026-04-21 17:24 ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 05/17] bpf: Introduce bpf register BPF_REG_PARAMS Yonghong Song
2026-04-19 17:06 ` sashiko-bot
2026-04-19 18:14 ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 06/17] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 07/17] bpf: Support stack arguments for bpf functions Yonghong Song
2026-04-19 19:15 ` sashiko-bot
2026-04-20 4:35 ` Yonghong Song
2026-04-21 0:37 ` Alexei Starovoitov
2026-04-21 4:15 ` Yonghong Song
2026-04-19 16:33 ` [PATCH bpf-next v6 08/17] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-04-19 18:21 ` sashiko-bot
2026-04-20 4:23 ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 09/17] bpf: Track r11 registers in const_fold and liveness Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 10/17] bpf: Prepare architecture JIT support for stack arguments Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 11/17] bpf: Enable r11 based insns Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 12/17] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-04-19 17:08 ` sashiko-bot
2026-04-19 18:18 ` Yonghong Song [this message]
2026-04-19 16:34 ` [PATCH bpf-next v6 13/17] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-04-19 17:08 ` sashiko-bot
2026-04-19 18:20 ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 14/17] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-04-19 17:25 ` sashiko-bot
2026-04-19 18:55 ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 15/17] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-04-19 17:15 ` sashiko-bot
2026-04-20 5:52 ` Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 16/17] selftests/bpf: Add tests for stack argument validation Yonghong Song
2026-04-19 16:34 ` [PATCH bpf-next v6 17/17] selftests/bpf: Add verifier " Yonghong Song
2026-04-19 17:21 ` sashiko-bot
2026-04-20 6:14 ` Yonghong Song
2026-04-20 15:41 ` [PATCH bpf-next v6 00/17] bpf: Support stack arguments for BPF functions and kfuncs Puranjay Mohan
2026-04-20 20:22 ` Yonghong Song
2026-04-20 20:25 ` Puranjay Mohan
2026-04-20 21:49 ` Alexei Starovoitov
2026-04-20 23:44 ` Yonghong Song
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=1e100198-b8df-41a5-a0b1-f22a572def4b@linux.dev \
--to=yonghong.song@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko@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