[PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest

[PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest

[Zhenzhong Wu]

Add a verifier runtime test for a branch pattern where a helper return
value and a related scalar stay live across the same control-flow
sequence. Rust/Aya-generated eBPF can naturally produce this shape when
a match on a helper status keeps data derived before the helper call
live across the same branches. Such code commonly uses the helper return
value in r0, where 0 means success, producing an r0 == 0 / r0 != 0
branch shape.

The test preserves that branch shape but shifts the success value to 1
before branching. Using r0 == 1 / r0 != 1 avoids depending on the
verifier's not-equal-zero refinement, so the test exercises linked
scalar precision and pruning behavior directly instead of being masked
by zero-specific range refinement.

On affected kernels the verifier can explore an impossible path where
r0 and r7 are linked by scalar ID, keep the wrong branch, and make the
test return 1. With linked scalar precision tracked per instruction,
state pruning keeps the real success path, and the test returns 0.

Suggested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
 .../selftests/bpf/progs/verifier_scalar_ids.c | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
index 70ae14d60..de71d547f 100644
--- a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
+++ b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
@@ -448,6 +448,41 @@ __naked void linked_regs_broken_link_2(void)
 	: __clobber_all);
 }
 
+SEC("tc")
+__description("helper retval linked scalar pruning")
+__success __retval(0)
+__naked void helper_retval_linked_scalar_pruning(void)
+{
+	asm volatile (
+	"r7 = *(u32 *)(r1 + %[__sk_buff_data_end]);"
+	"r5 = *(u32 *)(r1 + %[__sk_buff_data]);"
+	"r7 -= r5;"
+	"r2 = 0;"
+	"r3 = r10;"
+	"r3 += -8;"
+	"r4 = 1;"
+	"call %[bpf_skb_load_bytes];"
+	"r0 += 1;"
+	"r6 = 1;"
+	/* success path keeps r7 independent; failure path links r7 to r0. */
+	"if r0 == 1 goto l0_%=;"
+	"r7 = r0;"
+"l0_%=: if r0 != 1 goto l1_%=;"
+	"r7 <<= 32;"
+	"r7 >>= 32;"
+	"if r7 != %[test_data_len] goto l1_%=;"
+	"r0 = 0;"
+	"exit;"
+"l1_%=: r0 = r6;"
+	"exit;"
+	:
+	: __imm(bpf_skb_load_bytes),
+	  __imm_const(__sk_buff_data, offsetof(struct __sk_buff, data)),
+	  __imm_const(__sk_buff_data_end, offsetof(struct __sk_buff, data_end)),
+	  __imm_const(test_data_len, TEST_DATA_LEN)
+	: __clobber_all);
+}
+
 /* Check that mark_chain_precision() for one of the conditional jump
  * operands does not trigger equal scalars precision propagation.
  */

base-commit: 30dee2c176e7954f63d1fa3e52d172f30beb9bfb
-- 
2.43.0

Re: [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest

[Alexei Starovoitov]

On Thu Jun 11, 2026 at 9:07 AM PDT, Zhenzhong Wu wrote:
> Add a verifier runtime test for a branch pattern where a helper return
> value and a related scalar stay live across the same control-flow
> sequence. Rust/Aya-generated eBPF can naturally produce this shape when
> a match on a helper status keeps data derived before the helper call
> live across the same branches. Such code commonly uses the helper return
> value in r0, where 0 means success, producing an r0 == 0 / r0 != 0
> branch shape.
>
> The test preserves that branch shape but shifts the success value to 1
> before branching. Using r0 == 1 / r0 != 1 avoids depending on the
> verifier's not-equal-zero refinement, so the test exercises linked
> scalar precision and pruning behavior directly instead of being masked
> by zero-specific range refinement.
>
> On affected kernels the verifier can explore an impossible path where
> r0 and r7 are linked by scalar ID, keep the wrong branch, and make the
> test return 1. With linked scalar precision tracked per instruction,
> state pruning keeps the real success path, and the test returns 0.
>
> Suggested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
> Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
> ---
>  .../selftests/bpf/progs/verifier_scalar_ids.c | 35 +++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
> index 70ae14d60..de71d547f 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
> @@ -448,6 +448,41 @@ __naked void linked_regs_broken_link_2(void)
>  	: __clobber_all);
>  }
>  
> +SEC("tc")
> +__description("helper retval linked scalar pruning")
> +__success __retval(0)
> +__naked void helper_retval_linked_scalar_pruning(void)
> +{
> +	asm volatile (
> +	"r7 = *(u32 *)(r1 + %[__sk_buff_data_end]);"
> +	"r5 = *(u32 *)(r1 + %[__sk_buff_data]);"
> +	"r7 -= r5;"
> +	"r2 = 0;"
> +	"r3 = r10;"
> +	"r3 += -8;"
> +	"r4 = 1;"
> +	"call %[bpf_skb_load_bytes];"
> +	"r0 += 1;"
> +	"r6 = 1;"
> +	/* success path keeps r7 independent; failure path links r7 to r0. */
> +	"if r0 == 1 goto l0_%=;"

this exercises linked registers with BPF_ADD_CONST logic.
We already have such tests. Why do we need this one?
How is it different?

pw-bot: cr

Re: [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest

[bot+bpf-ci]

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

> selftests/bpf: add helper retval linked scalar pruning selftest
>
>     Add a verifier runtime test for a branch pattern where a helper return
>     value and a related scalar stay live across the same control-flow
>     sequence. Rust/Aya-generated eBPF can naturally produce this shape when
>     a match on a helper status keeps data derived before the helper call
>     live across the same branches. Such code commonly uses the helper return
>     value in r0, where 0 means success, producing an r0 == 0 / r0 != 0
>     branch shape.
>
>     The test preserves that branch shape but shifts the success value to 1
>     before branching. Using r0 == 1 / r0 != 1 avoids depending on the
>     verifier's not-equal-zero refinement, so the test exercises linked
>     scalar precision and pruning behavior directly instead of being masked
>     by zero-specific range refinement.
>
>     On affected kernels the verifier can explore an impossible path where
>     r0 and r7 are linked by scalar ID, keep the wrong branch, and make the
>     test return 1. With linked scalar precision tracked per instruction,
>     state pruning keeps the real success path, and the test returns 0.
>
>     Suggested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
>     Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>

This adds a regression test for a verifier state-pruning issue with
scalars linked by scalar ID, but there is no Fixes: tag.

The test structure (success path keeps r7 independent with id=0, failure
path links r7 to r0) matches the "registers with id=0 in cached state vs
linked in current state" pruning scenario that was addressed by changing
check_scalar_ids() and regsafe() to treat rold->id == 0 as independent.

Should this carry:

  Fixes: b0388bafa494 ("bpf: Relax scalar id equivalence for state pruning")


---
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/27361218656