From: sashiko-bot@kernel.org
To: "Vineet Gupta" <vineet.gupta@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC bpf-next 6/6] selftests/bpf: cover 32-bit sign-extension low-32 links
Date: Fri, 14 Aug 2026 23:27:18 +0000 [thread overview]
Message-ID: <20260814232719.064EC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814231945.3884596-7-vineet.gupta@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The failure tests `sext_dest_driven_does_not_narrow_base` and `zext_dest_driven_does_not_narrow_base` contain backwards branch conditions, making them unconditionally pass regardless of whether the verifier bug is present.
--
--- Patch [6]: [RFC bpf-next 6/6] selftests/bpf: cover 32-bit sign-extension low-32 links ---
commit f8b3195655d59866de20fa031cd9d9e1bbfbde94
Author: Vineet Gupta <vineet.gupta@linux.dev>
Subject: selftests/bpf: cover 32-bit sign-extension low-32 links
This commit adds selftests for the BPF_FLAG_SUBREG_SEXT link in the BPF
verifier. The tests verify various sign-extension behaviors, including
deduction through links, zero-extension interaction, and in-loop behavior.
> diff --git a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
> index 2cc6f9e45aff3..ff71e168d4cc4 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
[ ... ]
> @@ -826,4 +826,416 @@ l_out_%=: \
> : __clobber_all);
> }
>
[ ... ]
> +SEC("socket")
> +__failure __msg("div by zero")
> +__flag(BPF_F_TEST_STATE_FREQ)
> +__naked void sext_dest_driven_does_not_narrow_base(void)
> +{
> + asm volatile (" \
> + call %[bpf_get_prandom_u32]; \
> + r6 = r0; /* r6 low = unknown u32 */ \
> + call %[bpf_get_prandom_u32]; \
> + r0 <<= 32; \
> + r6 |= r0; /* r6 = full 64-bit unknown (base) */ \
> + r7 = (s32)r6; /* low-32 SEXT link */ \
> + if r7 != 0 goto l_out_%=;/* r7 == 0: low 32 bits are 0 */ \
> + if r6 != 0 goto l_out_%=;/* r6 may still have high bits set */ \
> + r0 /= 0; /* must stay reachable */ \
> +l_out_%=: \
> + r0 = 0; \
> + exit; \
> +" :
> + : __imm(bpf_get_prandom_u32)
> + : __clobber_all);
> +}
[Severity: Medium]
Are these branch conditions backward for a __failure test that expects a
"div by zero" rejection?
Since the test expects the division to be reachable for rejection, if the
buggy verifier deduces r6 == 0, "if r6 != 0 goto l_out_%=" will evaluate as
false and fall through to the division by zero, causing a rejection and
making the test pass.
If the verifier is correct, the fall-through is also reachable, causing a
rejection and passing the test.
Does this mean the test passes unconditionally regardless of whether the
verifier bug is present, causing a regression in test coverage?
Should this check instead be "if r6 == 0 goto l_out_%="? This way, if the
verifier makes the buggy deduction that r6 == 0, it takes the branch and
the div becomes unreachable, allowing the verifier to accept the program and
fail the test as intended.
It looks like the identical condition also exists in the pre-existing
zext_dest_driven_does_not_narrow_base() test just above this:
w7 = w6; /* low-32 ZEXT link */ \
if r7 != 0 goto l_out_%=;/* r7 == 0: low 32 bits are 0 */ \
if r6 != 0 goto l_out_%=;/* r6 may still have high bits set */ \
r0 /= 0; /* must stay reachable */ \
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814231945.3884596-1-vineet.gupta@linux.dev?part=6
prev parent reply other threads:[~2026-08-14 23:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 23:19 [RFC bpf-next 0/6] bpf: track scalar equality across the low 32 bits Vineet Gupta
2026-08-14 23:19 ` [RFC bpf-next 1/6] bpf: turn bpf_reg_state->precise into a flags field [NFC] Vineet Gupta
2026-08-14 23:19 ` [RFC bpf-next 2/6] bpf: move the linked-scalar flags into bpf_reg_state->flags [NFC] Vineet Gupta
2026-08-14 23:34 ` sashiko-bot
2026-08-14 23:19 ` [RFC bpf-next 3/6] bpf: support low-32 subreg scalar linking for zero-extending movs Vineet Gupta
2026-08-14 23:19 ` [RFC bpf-next 4/6] selftests/bpf: cover low-32 subreg-equal link " Vineet Gupta
2026-08-14 23:27 ` sashiko-bot
2026-08-14 23:19 ` [RFC bpf-next 5/6] bpf: support low-32 subreg scalar linking for sign-extending movs Vineet Gupta
2026-08-14 23:19 ` [RFC bpf-next 6/6] selftests/bpf: cover 32-bit sign-extension low-32 links Vineet Gupta
2026-08-14 23:27 ` sashiko-bot [this message]
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=20260814232719.064EC1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vineet.gupta@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.