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 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.