[PATCH bpf-next] selftests/bpf: Fix test for refinement of single-value tnum

[PATCH bpf-next] selftests/bpf: Fix test for refinement of single-value tnum

[Paul Chaignon]

This patch fixes the "bounds refinement with single-value tnum on umin"
verifier selftest. This selftest was introduced in commit e6ad477d1bf8
("selftests/bpf: Test refinement of single-value tnum") to cover the
logic from __update_reg64_bounds(), introduced in commit efc11a667878
("bpf: Improve bounds when tnum has a single possible value"). However,
the test still passes if that last commit is reverted.

The test is supposed to cover the case when the tnum and u64 range (or
cnum64 now) overlap in a single value. __update_reg64_bounds() detects
that case and refines the bounds to a known constant. However, the
constants for the test were poorly chosen and the bounds get refined to
a known constant even without __update_reg64_bounds(). The code is as
follows:

  0: call bpf_get_prandom_u32#7  ; R0=scalar()
  1: r0 |= 224                   ; R0=scalar(umin=umin32=224,var_off=(0xe0; 0xffffffffffffff1f))
  2: r0 &= 240                   ; R0=scalar(smin=umin=smin32=umin32=224,smax=umax=smax32=umax32=240,var_off=(0xe0; 0x10))
  3: if r0 == 0xf0 goto pc+2     ; R0=224

After instruction 3, we have u64=[0xe0; 0xef] and tnum=(0xe0; 0x10).
__reg_bound_offset() is able to deduce a new tnum from the u64,
tnum=(0xe0; 0x0f), which combined with the existing tnum gives us a
constant: 0xe0 or 224.

We can easily fix this by choosing different starting bounds. If we make
it u64=[0xe1; 0xf0], then __reg_bound_offset() doesn't have any impact.

Fixes: e6ad477d1bf8 ("selftests/bpf: Test refinement of single-value tnum")
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
---
 .../testing/selftests/bpf/progs/verifier_bounds.c  | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds.c b/tools/testing/selftests/bpf/progs/verifier_bounds.c
index a3e4c0945137..bc038ac2df98 100644
--- a/tools/testing/selftests/bpf/progs/verifier_bounds.c
+++ b/tools/testing/selftests/bpf/progs/verifier_bounds.c
@@ -1892,25 +1892,25 @@ __naked void bounds_refinement_tnum_umax(void *ctx)
 /* This test covers the bounds deduction when the u64 range and the tnum
  * overlap only at umin. After instruction 3, the ranges look as follows:
  *
- * 0    umin=0xe00     umax=0xeff                              U64_MAX
+ * 0    umin=0xe1      umax=0xf0                               U64_MAX
  * |    [xxxxxxxxxxxxxx]                                       |
  * |----------------------------|------------------------------|
  * |    x               x                                      | tnum values
  *
- * The verifier can therefore deduce that the R0=0xe0=224.
+ * The verifier can therefore deduce that the R0=0xe1=225.
  */
 SEC("socket")
 __description("bounds refinement with single-value tnum on umin")
-__msg("3: (15) if r0 == 0xf0 {{.*}} R0=224")
+__msg("3: (15) if r0 == 0xf1 {{.*}} R0=225")
 __success __log_level(2)
 __naked void bounds_refinement_tnum_umin(void *ctx)
 {
 	asm volatile("			\
 	call %[bpf_get_prandom_u32];	\
-	r0 |= 0xe0;			\
-	r0 &= 0xf0;			\
-	if r0 == 0xf0 goto +2;		\
-	if r0 == 0xe0 goto +1;		\
+	r0 |= 0xe1;			\
+	r0 &= 0xf1;			\
+	if r0 == 0xf1 goto +2;		\
+	if r0 == 0xe1 goto +1;		\
 	r10 = 0;			\
 	exit;				\
 "	:
-- 
2.43.0

Re: [PATCH bpf-next] selftests/bpf: Fix test for refinement of single-value tnum

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

> diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds.c b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> index a3e4c0945137..bc038ac2df98 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_bounds.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> @@ -1892,25 +1892,25 @@ __naked void bounds_refinement_tnum_umax(void *ctx)
>  /* This test covers the bounds deduction when the u64 range and the tnum
>   * overlap only at umin. After instruction 3, the ranges look as follows:
>   *
> - * 0    umin=0xe00     umax=0xeff                              U64_MAX
> + * 0    umin=0xe1      umax=0xf0                               U64_MAX
                              ^^^^^

The comment says umax=0xf0 but looking at the code change below:

>   * |    [xxxxxxxxxxxxxx]                                       |
>   * |----------------------------|------------------------------|
>   * |    x               x                                      | tnum values
>   *
> - * The verifier can therefore deduce that the R0=0xe0=224.
> + * The verifier can therefore deduce that the R0=0xe1=225.
>   */
>  SEC("socket")
>  __description("bounds refinement with single-value tnum on umin")
> -__msg("3: (15) if r0 == 0xf0 {{.*}} R0=224")
> +__msg("3: (15) if r0 == 0xf1 {{.*}} R0=225")
>  __success __log_level(2)
>  __naked void bounds_refinement_tnum_umin(void *ctx)
>  {
>  	asm volatile("			\
>  	call %[bpf_get_prandom_u32];	\
> -	r0 |= 0xe0;			\
> -	r0 &= 0xf0;			\
> -	if r0 == 0xf0 goto +2;		\
> -	if r0 == 0xe0 goto +1;		\
> +	r0 |= 0xe1;			\
> +	r0 &= 0xf1;			\
                   ^^^^

After r0 |= 0xe1, the register has umin=0xe1. Then after r0 &= 0xf1,
the mask 0xf1 allows bits 11110001, which permits both 0xe1 and 0xf1.
This creates a u64 range of [0xe1, 0xf1], not [0xe1, 0xf0] as stated
in the comment.

Should the comment be updated to umax=0xf1 to match the implementation?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26047251229

Re: [PATCH bpf-next] selftests/bpf: Fix test for refinement of single-value tnum

[Paul Chaignon]

On Mon, May 18, 2026 at 05:09:21PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds.c b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> > index a3e4c0945137..bc038ac2df98 100644
> > --- a/tools/testing/selftests/bpf/progs/verifier_bounds.c
> > +++ b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> > @@ -1892,25 +1892,25 @@ __naked void bounds_refinement_tnum_umax(void *ctx)
> >  /* This test covers the bounds deduction when the u64 range and the tnum
> >   * overlap only at umin. After instruction 3, the ranges look as follows:
> >   *
> > - * 0    umin=0xe00     umax=0xeff                              U64_MAX
> > + * 0    umin=0xe1      umax=0xf0                               U64_MAX
>                               ^^^^^
> 
> The comment says umax=0xf0 but looking at the code change below:
> 
> >   * |    [xxxxxxxxxxxxxx]                                       |
> >   * |----------------------------|------------------------------|
> >   * |    x               x                                      | tnum values
> >   *
> > - * The verifier can therefore deduce that the R0=0xe0=224.
> > + * The verifier can therefore deduce that the R0=0xe1=225.
> >   */
> >  SEC("socket")
> >  __description("bounds refinement with single-value tnum on umin")
> > -__msg("3: (15) if r0 == 0xf0 {{.*}} R0=224")
> > +__msg("3: (15) if r0 == 0xf1 {{.*}} R0=225")
> >  __success __log_level(2)
> >  __naked void bounds_refinement_tnum_umin(void *ctx)
> >  {
> >  	asm volatile("			\
> >  	call %[bpf_get_prandom_u32];	\
> > -	r0 |= 0xe0;			\
> > -	r0 &= 0xf0;			\
> > -	if r0 == 0xf0 goto +2;		\
> > -	if r0 == 0xe0 goto +1;		\
> > +	r0 |= 0xe1;			\
> > +	r0 &= 0xf1;			\
>                    ^^^^
> 
> After r0 |= 0xe1, the register has umin=0xe1. Then after r0 &= 0xf1,
> the mask 0xf1 allows bits 11110001, which permits both 0xe1 and 0xf1.
> This creates a u64 range of [0xe1, 0xf1], not [0xe1, 0xf0] as stated
> in the comment.

That's correct. But after instruction 3, on the fallthrough path, we can
also deduce that R0 != 0xf1 and our existing refinement logic can thus
tighten the u64 range to [0xe1; 0xf0]. The comment is therefore correct.

> 
> Should the comment be updated to umax=0xf1 to match the implementation?
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26047251229

Re: [PATCH bpf-next] selftests/bpf: Fix test for refinement of single-value tnum

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Mon, 18 May 2026 18:26:35 +0200 you wrote:
> This patch fixes the "bounds refinement with single-value tnum on umin"
> verifier selftest. This selftest was introduced in commit e6ad477d1bf8
> ("selftests/bpf: Test refinement of single-value tnum") to cover the
> logic from __update_reg64_bounds(), introduced in commit efc11a667878
> ("bpf: Improve bounds when tnum has a single possible value"). However,
> the test still passes if that last commit is reverted.
> 
> [...]

Here is the summary with links:
  - [bpf-next] selftests/bpf: Fix test for refinement of single-value tnum
    https://git.kernel.org/bpf/bpf-next/c/523d2f42b406

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html