public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 03/16] bpf: Refactor to handle memory and size together
Date: Fri, 17 Apr 2026 04:49:13 +0000	[thread overview]
Message-ID: <20260417044914.84018C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260417034713.2627100-1-yonghong.song@linux.dev>

Sashiko AI review found 1 potential issue(s):
- [High] Incomplete refactoring for stack arguments breaks verifier precision tracking, marking incorrect registers.
--

commit 7bebb6c179745d67fba0c807428d095b66738135
Author: Yonghong Song <yonghong.song@linux.dev>

bpf: Refactor to handle memory and size together

This commit refactors memory and size register handling in BPF helper
verification, passing bpf_reg_state directly to prepare for stack arguments.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 2bedaa193d54d..7a7024d94cf00 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -7020,15 +7020,17 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno,
>  /* verify arguments to helpers or kfuncs consisting of a pointer and an access
>   * size.
>   *
> - * @regno is the register containing the access size. regno-1 is the register
> - * containing the pointer.
> + * @mem_regno is the register containing the pointer, mem_regno+1 is the register
> + * containing the access size.
>   */
>  static int check_mem_size_reg(struct bpf_verifier_env *env,
> -			      struct bpf_reg_state *reg, u32 regno,
> +			      struct bpf_reg_state *mem_reg,
> +			      struct bpf_reg_state *size_reg, u32 mem_regno,
>  			      enum bpf_access_type access_type,
>  			      bool zero_size_allowed,
>  			      struct bpf_call_arg_meta *meta)
>  {
> +	int size_regno = mem_regno + 1;
>  	int err;

Since this refactoring is intended to support stack arguments, does this
hardcoded size_regno = mem_regno + 1 break verifier precision tracking?

If the memory pointer is passed in R5, mem_regno is 5, making size_regno 6.

This would cause mark_chain_precision() to incorrectly backtrack the
callee-saved register BPF_REG_6 instead of the stack slot containing the size
argument.

Furthermore, if mem_regno is later modified to represent a 0-based argument
index, size_regno will evaluate to the wrong register entirely.

[ ... ]
> -	err = check_helper_mem_access(env, regno - 1, reg->umax_value,
> +	err = check_helper_mem_access(env, mem_reg, mem_regno, size_reg->umax_value,
>  				      access_type, zero_size_allowed, meta);
>  	if (!err)
> -		err = mark_chain_precision(env, regno);
> +		err = mark_chain_precision(env, size_regno);

Does marking the wrong register leave the actual size argument imprecise,
potentially corrupting verifier state pruning and allowing out-of-bounds
memory accesses to bypass verification?

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

  reply	other threads:[~2026-04-17  4:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-17  3:46 [PATCH bpf-next v5 00/16] bpf: Support stack arguments for BPF functions and kfuncs Yonghong Song
2026-04-17  3:47 ` [PATCH bpf-next v5 01/16] bpf: Remove unused parameter from check_map_kptr_access() Yonghong Song
2026-04-17  3:47 ` [PATCH bpf-next v5 02/16] bpf: Refactor to avoid redundant calculation of bpf_reg_state Yonghong Song
2026-04-17  3:47 ` [PATCH bpf-next v5 03/16] bpf: Refactor to handle memory and size together Yonghong Song
2026-04-17  4:49   ` sashiko-bot [this message]
2026-04-18  0:52   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 04/16] bpf: Prepare verifier logs for upcoming kfunc stack arguments Yonghong Song
2026-04-17  3:47 ` [PATCH bpf-next v5 05/16] bpf: Introduce bpf register BPF_REG_PARAMS Yonghong Song
2026-04-17  3:47 ` [PATCH bpf-next v5 06/16] bpf: Limit the scope of BPF_REG_PARAMS usage Yonghong Song
2026-04-17  4:30   ` bot+bpf-ci
2026-04-17  4:50   ` sashiko-bot
2026-04-18  1:04   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 07/16] bpf: Reuse MAX_BPF_FUNC_ARGS for maximum number of arguments Yonghong Song
2026-04-17  4:30   ` bot+bpf-ci
2026-04-18  0:52   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 08/16] bpf: Support stack arguments for bpf functions Yonghong Song
2026-04-17  4:35   ` sashiko-bot
2026-04-17  4:43   ` bot+bpf-ci
2026-04-18  1:04   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 09/16] bpf: Reject stack arguments in non-JITed programs Yonghong Song
2026-04-17  4:30   ` bot+bpf-ci
2026-04-18  0:52   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 10/16] bpf: Reject stack arguments if tail call reachable Yonghong Song
2026-04-17  4:08   ` sashiko-bot
2026-04-17  4:30   ` bot+bpf-ci
2026-04-18  1:04   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 11/16] bpf: Support stack arguments for kfunc calls Yonghong Song
2026-04-17  4:40   ` sashiko-bot
2026-04-17  4:43   ` bot+bpf-ci
2026-04-18  1:04   ` bot+bpf-ci
2026-04-17  3:47 ` [PATCH bpf-next v5 12/16] bpf: Enable stack argument support for x86_64 Yonghong Song
2026-04-17  4:30   ` bot+bpf-ci
2026-04-17  5:03   ` sashiko-bot
2026-04-18  1:04   ` bot+bpf-ci
2026-04-17  3:48 ` [PATCH bpf-next v5 13/16] bpf,x86: Implement JIT support for stack arguments Yonghong Song
2026-04-17  4:44   ` sashiko-bot
2026-04-17  3:48 ` [PATCH bpf-next v5 14/16] selftests/bpf: Add tests for BPF function " Yonghong Song
2026-04-17  4:20   ` sashiko-bot
2026-04-18  0:52   ` bot+bpf-ci
2026-04-17  3:48 ` [PATCH bpf-next v5 15/16] selftests/bpf: Add negative test for greater-than-8-byte kfunc stack argument Yonghong Song
2026-04-17  4:28   ` sashiko-bot
2026-04-18  0:52   ` bot+bpf-ci
2026-04-17  3:48 ` [PATCH bpf-next v5 16/16] selftests/bpf: Add verifier tests for stack argument validation Yonghong Song
2026-04-17  4:38   ` sashiko-bot
2026-04-18  0:52   ` bot+bpf-ci

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=20260417044914.84018C19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    --cc=yonghong.song@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