Re: [PATCH bpf-next v3 05/12] selftests/bpf: Cover the low-32 link for zero-extending movs
From: Vineet Gupta
Date: Mon Oct 26 2026 - 14:40:41 EST
On 10/20/26 9:53 AM, bot+bpf-ci@xxxxxxxxxx wrote:
selftests/bpf: Cover the low-32 link for zero-extending movsTL;DR:
- Selftest comment calls the mixed-kind no-sync case unsound, but the program
is safe; it is only lost precision
- Commit message says "Twelve" programs, but there are thirteen
selftests/bpf: Cover the low-32 link for zero-extending movsThe changelog says "Twelve programs", but the list below it has thirteen
Twelve programs, one per decision the previous patch makes:
- zext_mov_narrow_src: narrowing the source reaches the destination
- zext_sync_makes_member_const: and over all 64 bits, since the member
is the zero-extension
- zext_narrow_dst_keeps_base: the reverse must not happen
- zext_u32_src_is_full_link: a provably-u32 source still propagates
- zext_self_mov_no_link: a self-mov mints no id
- zext_chain_drops_link: a second 32-bit mov drops the link
- zext_no_sync_between_mixed_kinds: differing kinds do not reach each
other, in either direction
- zext_no_sync_from_subreg_base: nor does a member reach a base whose
high half it knows nothing about
- zext_sync_between_two_subregs: two low-32 links on one base do
- zext_unlinked_path_stays_reachable: one unlinked path keeps the
guarded div reachable
- zext_mov_breaks_linked_src: forming the link drops the source's own
- zext_sync_keeps_narrower_member: narrowing the base does not widen a
member that already proved itself tighter
- zext_contradiction_keeps_range_sane: a contradiction leaves no empty
range behind, under BPF_F_TEST_REG_INVARIANTS so the violation is a
load failure rather than something only dmesg sees
Written in asm so the bytecode is the same whichever compiler built the
suite.
Signed-off-by: Vineet Gupta <vineet.gupta@xxxxxxxxx>
bullets, and the patch adds thirteen programs:
zext_mov_narrow_src, zext_sync_makes_member_const,
zext_contradiction_keeps_range_sane, zext_narrow_dst_keeps_base,
zext_u32_src_is_full_link, zext_self_mov_no_link, zext_chain_drops_link,
zext_no_sync_between_mixed_kinds, zext_no_sync_from_subreg_base,
zext_sync_between_two_subregs, zext_sync_keeps_narrower_member,
zext_unlinked_path_stays_reachable and zext_mov_breaks_linked_src.
The count looks like it was not updated when
zext_contradiction_keeps_range_sane was added. It is the last bullet, but the
third program in the file. Should "Twelve" be "Thirteen"?
Yes there was a last minute test update and this missed the update.
diff --git a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c[ ... ]
--- a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
+++ b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
@@ -710,4 +710,352 @@ l_exit_%=: \[ ... ]
+/*^^^^
+ * Two members of one id set carrying different link kinds do not propagate
+ * to each other: r7 is (u32)base and r8 is base + 3, and the deltas were
+ * added at different ALU widths, so narrowing r8 says nothing about r7.
+ * sync_linked_regs() declines the pair on the kinds before the deltas are
+ * ever consulted. Note neither register is the base -- that is r6.
+ */
+SEC("socket")
+__failure __msg("div by zero")
+__naked void zext_no_sync_between_mixed_kinds(void)
+{
+ asm volatile (" \
+ call %[bpf_get_prandom_u32]; \
+ r6 = r0; \
+ w7 = w6; /* forms the link */ \
+ r8 = r6; \
+ r8 += 3; /* r8 is BPF_REG_LINK_FULL, r7 is BPF_REG_LINK_ZEXT */ \
+ if r8 != 3 goto 1f; /* must not propagate to r7 */ \
+ if w7 == 0 goto 1f; \
+ r0 /= 0; \
+1: \
+ r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_get_prandom_u32)
+ : __clobber_all);
+}
This isn't a bug, but is the comment accurate for this direction? It says
narrowing r8 "says nothing about r7", and the asm comment says the narrowing
"must not propagate to r7".
r8 is a BPF_REG_LINK_FULL member, so r8 == r6 + 3 over all 64 bits. That
relation inverts exactly, so knowing r8 pins the base, and r7 == (u32)(r8 - 3)
follows.
In this program the fall-through of "if r8 != 3 goto 1f" forces r6 == 0, so
r7 == 0, "if w7 == 0 goto 1f" is always taken, and "r0 /= 0" cannot be reached
at runtime. The program is safe. The verifier rejects it only because
sync_linked_regs() skips every pair with differing kinds:
if (reg->link_kind && known_reg->link_kind &&
reg->link_kind != known_reg->link_kind)
continue;
That check exists for the other direction, a ZEXT known_reg against a FULL
member (scalars_alu32_alu64_cross_type), where the 32-bit wrap really does
break the relation. If the differencing arm ran for known=r8 (FULL, delta 3)
and reg=r7 (ZEXT, delta 0), it would compute r8 + (0 - 3) and then
zext_32_to_64(), which gives exactly (u32)(r8 - 3). That is sound.
So this test pins a deliberate loss of precision, not a soundness requirement,
but the comment presents it as unsound. The text is unchanged at the tip of
the series. Someone who later makes the verifier propagate FULL -> ZEXT will
see this test fail, and the comment will suggest the improvement is wrong.
zext_chain_drops_link and zext_mov_breaks_linked_src also reject runtime-safe
programs, but their comments say the link is dropped by rule. Could this one
be worded the same way, for example "sync_linked_regs() declines mixed kinds
even where, as here, the relation would hold"?
Yes this is correct as well, I'll update the comments.
Thx,
-Vineet
---
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/39458500836