From: Vineet Gupta <vineet.gupta@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 10/13] selftests/bpf: cover the low-32 link for narrowing stack fills
Date: Fri, 11 Sep 2026 11:04:29 +0530 [thread overview]
Message-ID: <4ef9a3d4-7a79-4144-baff-e236f8eb7c5e@linux.dev> (raw)
In-Reply-To: <20260910170020.04A4E1F000FF@smtp.kernel.org>
On 9/10/26 10:30 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The newly added tests for narrow stack fills hardcode memory offsets (e.g., `(r10 - 8)`) which are only correct on little-endian architectures. On big-endian architectures like s390x, these offsets do not point to the lower bits, causing the BPF verifier to reject the programs and resulting in test failures.
> --
>
> commit a42f9a6d4d49f17385f014eede55d6e82094a838
> Author: Vineet Gupta <vineet.gupta@linux.dev>
>
> selftests/bpf: cover the low-32 link for narrowing stack fills
>
> This commit adds five new BPF programs to test the verifier's handling of
> narrowing stack fills, specifically targeting low-32 links and sign-extension
> behavior.
>
>> 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
> [ ... ]
>
>> +SEC("socket")
>> +__success
>> +__naked void zext_fill_narrow_from_wide_spill(void)
>> +{
>> + asm volatile (" \
>> + call %[bpf_get_prandom_u32]; \
>> + r6 = r0; \
>> + call %[bpf_get_prandom_u32]; \
>> + r0 <<= 32; \
>> + r6 |= r0; /* r6 = full 64-bit unknown */ \
>> + *(u64 *)(r10 - 8) = r6; /* slot linked to r6 */ \
>> + r2 = *(u32 *)(r10 - 8); /* narrowing fill, forms the link */ \
> [Severity: Medium]
> On big-endian architectures like s390x, won't reading 32 bits from offset -8
> target the upper 32 bits instead of the lower 32 bits?
>
> The bpf_stack_narrow_access_ok() check in the verifier expects to read the
> least significant bytes of the spill slot, which on big-endian are located
> at offset -4 for a 32-bit read. Could this hardcoded offset cause the verifier
> to reject the program and break the test on big-endian systems?
Goot catch. Fixed for BE and LE.
>> + if w6 != 0 goto 1f; /* narrows r6, propagates to r2 */ \
>> + if r2 == 0 goto 1f; \
>> + r0 /= 0; \
>> +1: \
>> + r0 = 0; \
>> + exit; \
>> +" :
>> + : __imm(bpf_get_prandom_u32)
>> + : __clobber_all);
>> +}
> [ ... ]
>
>> +SEC("socket")
>> +__failure __msg("div by zero")
>> +__naked void zext_fill_byte_forms_no_link(void)
>> +{
>> + asm volatile (" \
>> + call %[bpf_get_prandom_u32]; \
>> + r6 = r0; \
>> + call %[bpf_get_prandom_u32]; \
>> + r0 <<= 32; \
>> + r6 |= r0; \
>> + *(u64 *)(r10 - 8) = r6; \
>> + r2 = *(u8 *)(r10 - 8); /* 1-byte fill: no link */ \
> [Severity: Medium]
> Does this hardcoded 8-bit read from offset -8 target the most significant byte
> rather than the least significant byte on big-endian architectures?
Fixed.
>> + if w6 != 0 goto 1f; \
>> + if r2 == 0 goto 1f; /* not deduced */ \
>> + r0 /= 0; \
>> +1: \
>> + r0 = 0; \
>> + exit; \
>> +" :
>> + : __imm(bpf_get_prandom_u32)
>> + : __clobber_all);
>> +}
> [ ... ]
>
>> +SEC("socket")
>> +__success
>> +__naked void sext_fill_narrow_from_wide_spill(void)
>> +{
>> + asm volatile (" \
>> + call %[bpf_get_prandom_u32]; \
>> + r6 = r0; \
>> + call %[bpf_get_prandom_u32]; \
>> + r0 <<= 32; \
>> + r6 |= r0; /* r6 = full 64-bit unknown */ \
>> + *(u64 *)(r10 - 8) = r6; /* slot linked to r6 */ \
>> + r2 = *(s32 *)(r10 - 8); /* narrowing sx fill */ \
> [Severity: Medium]
> Similar to the previous cases, will this 32-bit read from offset -8 read the
> upper 32 bits on big-endian systems and cause verifier bounds tracking to fail?
Fixed.
>> + if w6 != -1 goto 1f; /* narrows r6, propagates to r2 */ \
>> + if r2 == -1 goto 1f; /* sign-extended, not 0xffffffff */ \
>> + r0 /= 0; \
>> +1: \
>> + r0 = 0; \
>> + exit; \
>> +" :
>> + : __imm(bpf_get_prandom_u32)
>> + : __clobber_all);
>> +}
> [ ... ]
>
>> +SEC("socket")
>> +__failure __msg("div by zero")
>> +__flag(BPF_F_TEST_STATE_FREQ)
>> +__naked void fill_kinds_reach_different_values(void)
>> +{
>> + asm volatile (" \
>> + call %[bpf_get_prandom_u32]; \
>> + r6 = r0; \
>> + r6 &= 1; \
>> + call %[bpf_get_prandom_u32]; \
>> + r8 = r0; \
>> + call %[bpf_get_prandom_u32]; \
>> + r0 <<= 32; \
>> + r8 |= r0; \
>> + *(u64 *)(r10 - 8) = r8; \
>> + if r6 >= 1 goto 2f; \
>> + r2 = *(s32 *)(r10 - 8); /* sign-extending fill */ \
> [Severity: Medium]
> Will these narrow fills also fail verifier checks on big-endian machines due
> to the fixed -8 offset pointing to the wrong 32-bit half?
Fixed.
>
>> + goto 1f; \
>> +2: \
>> + r2 = *(u32 *)(r10 - 8); /* zero-extending fill */ \
>> +1: \
>> + if w8 != -1 goto 3f; \
>> + if r2 == -1 goto 3f; /* only the sign-extending path */ \
next prev parent reply other threads:[~2026-09-11 5:34 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 16:46 [PATCH bpf-next v2 00/13] bpf: track scalar equality across the low 32 bits Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 01/13] bpf: move linked-scalar flags out of bpf_reg_state->id [NFC] Vineet Gupta
2026-09-10 17:00 ` sashiko-bot
2026-09-11 6:56 ` Vineet Gupta
2026-09-10 17:52 ` bot+bpf-ci
2026-09-12 18:50 ` Alexei Starovoitov
2026-09-10 16:46 ` [PATCH bpf-next v2 02/13] bpf: compare linked-scalar kinds in regs_exact() Vineet Gupta
2026-09-12 18:51 ` Alexei Starovoitov
2026-09-10 16:46 ` [PATCH bpf-next v2 03/13] bpf: track low-32 scalar equality across zero-extending movs Vineet Gupta
2026-09-10 17:52 ` bot+bpf-ci
2026-09-11 9:29 ` Vineet Gupta
2026-09-12 18:59 ` Alexei Starovoitov
2026-09-10 16:46 ` [PATCH bpf-next v2 04/13] selftests/bpf: cover the low-32 link for " Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 05/13] bpf: keep the range across a sign extension that cannot change it Vineet Gupta
2026-09-10 17:08 ` sashiko-bot
2026-09-10 17:52 ` bot+bpf-ci
2026-09-11 10:37 ` Vineet Gupta
2026-09-12 19:02 ` Alexei Starovoitov
2026-09-10 16:46 ` [PATCH bpf-next v2 06/13] selftests/bpf: cover sign extensions that cannot change the range Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 07/13] bpf: track low-32 scalar equality across sign-extending movs Vineet Gupta
2026-09-10 17:52 ` bot+bpf-ci
2026-09-11 10:00 ` Vineet Gupta
2026-09-12 19:09 ` Alexei Starovoitov
2026-09-10 16:46 ` [PATCH bpf-next v2 08/13] selftests/bpf: cover the low-32 link for " Vineet Gupta
2026-09-10 17:52 ` bot+bpf-ci
2026-09-11 8:00 ` Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 09/13] bpf: track low-32 scalar equality across narrowing stack fills Vineet Gupta
2026-09-10 17:04 ` sashiko-bot
2026-09-11 6:07 ` Vineet Gupta
2026-09-11 6:43 ` Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 10/13] selftests/bpf: cover the low-32 link for " Vineet Gupta
2026-09-10 17:00 ` sashiko-bot
2026-09-11 5:34 ` Vineet Gupta [this message]
2026-09-10 17:31 ` bot+bpf-ci
2026-09-11 5:07 ` Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 11/13] bpf: record what a narrowing spill actually stores Vineet Gupta
2026-09-10 16:46 ` [PATCH bpf-next v2 12/13] bpf: track low-32 scalar equality across narrowing stack spills Vineet Gupta
2026-09-10 17:05 ` sashiko-bot
2026-09-10 16:46 ` [PATCH bpf-next v2 13/13] selftests/bpf: cover the low-32 link for " Vineet Gupta
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=4ef9a3d4-7a79-4144-baff-e236f8eb7c5e@linux.dev \
--to=vineet.gupta@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.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