From: sashiko-bot@kernel.org
To: "Daniel Borkmann" <daniel@iogearbox.net>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 4/4] selftests/bpf: Add test for arena pointer zext across state pruning
Date: Wed, 05 Aug 2026 20:14:41 +0000 [thread overview]
Message-ID: <20260805201442.5A8A01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805184444.292828-4-daniel@iogearbox.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The selftest uses a 64-bit instruction (`r6 = 0`) instead of a 32-bit instruction (`w6 = 0`), which zeroes the upper 32 bits and bypasses `BPF_F_TEST_RND_HI32` randomization, masking the bug it intends to catch.
- [Medium] The test's exit logic masks wild pointer faults via BPF exception tables, causing it to always return 0 (success) even if it successfully reproduces the bug.
--
--- Patch [4]: [PATCH bpf-next 4/4] selftests/bpf: Add test for arena pointer zext across state pruning ---
commit 230d6f79c5ec9b66b6dcd9f9c3cb999533024b62
Author: Daniel Borkmann <daniel@iogearbox.net>
selftests/bpf: Add test for arena pointer zext across state pruning
This patch adds a selftest to verify that the BPF verifier correctly marks
zero extension for arena pointers across state pruning. The test uses an
addr_space_cast and relies on BPF_F_TEST_RND_HI32 to ensure proper zero
extension on architectures like s390x.
> diff --git a/tools/testing/selftests/bpf/progs/verifier_arena.c b/tools/testing/selftests/bpf/progs/verifier_arena.c
> index b241bbcf54a8a..b5f5b81a27e71 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_arena.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_arena.c
[ ... ]
> @@ -635,6 +635,41 @@ int non_arena_ptr_add_to_arena_ptr(void *ctx)
[ ... ]
> + if r7 != 0 goto l1_%=; \
> + goto l0_%=; \
> +l1_%=: r6 = 0; /* 32-bit define */ \
[Severity: Medium]
Does using a 64-bit assignment here bypass the BPF_F_TEST_RND_HI32
randomization framework?
Since r6 = 0 translates to a BPF_ALU64 instruction, bpf_is_reg64() returns
true and the verifier's bpf_opt_subreg_zext_lo32_rnd_hi32() pass skips
instrumenting it. This prevents garbage from being injected into the upper 32
bits, masking the missing zero-extension bug the test intends to catch.
Would using a 32-bit assignment like w6 = 0 correctly trigger the
randomization?
> + r6 = addr_space_cast(r6, 0x0, 0x1); \
> +l0_%=: r0 = *(u32 *)(r6 + 0); /* 64-bit read */ \
> + r0 = 0; \
> + exit; \
[Severity: Medium]
Will this exit logic mask wild pointer faults?
Because r6 is a PTR_TO_ARENA, the verifier converts the out-of-bounds read
into a BPF_PROBE_MEM32 load. If r6 contains a wild garbage pointer and triggers
a page fault, the kernel's exception tables will silently catch it, zero r0,
and resume execution.
Since the test then explicitly executes r0 = 0 and exits, and the framework
expects __retval(0), it appears the test will unconditionally pass even if it
successfully reproduces the bug.
> +" :
> + : __imm_addr(arena),
> + __imm_const(__sk_buff_len, offsetof(struct __sk_buff, len))
> + : __clobber_all);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805184444.292828-1-daniel@iogearbox.net?part=4
next prev parent reply other threads:[~2026-08-05 20:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 18:44 [PATCH bpf-next 1/4] bpf: Mark pending sub-register zero extension before pruning a state Daniel Borkmann
2026-08-05 18:44 ` [PATCH bpf-next 2/4] bpf: Mark pending zero extension of arena ptrs " Daniel Borkmann
2026-08-05 18:44 ` [PATCH bpf-next 3/4] selftests/bpf: Add tests for sub-register zext across state pruning Daniel Borkmann
2026-08-05 18:44 ` [PATCH bpf-next 4/4] selftests/bpf: Add test for arena pointer " Daniel Borkmann
2026-08-05 20:14 ` sashiko-bot [this message]
2026-08-05 19:11 ` [PATCH bpf-next 1/4] bpf: Mark pending sub-register zero extension before pruning a state Eduard Zingerman
2026-08-05 19:54 ` Daniel Borkmann
2026-08-05 20:36 ` Eduard Zingerman
2026-08-05 20:22 ` sashiko-bot
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=20260805201442.5A8A01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--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