From: sashiko-bot@kernel.org
To: "Eduard Zingerman" <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 3/5] bpf: infer zext_dst based on static register liveness analysis
Date: Sun, 02 Aug 2026 21:07:41 +0000 [thread overview]
Message-ID: <20260802210741.D10C21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260802-static-zext-v3-3-3456b2604574@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Missing zero-extension for BPF_ADDR_SPACE_CAST allows out-of-bounds arena access on architectures needing explicit zero-extension.
--
--- Patch [3]: [PATCH bpf-next v3 3/5] bpf: infer zext_dst based on static register liveness analysis ---
commit 740202f3328f4855ad10128ef188400086445fa9
Author: Eduard Zingerman <eddyz87@gmail.com>
bpf: infer zext_dst based on static register liveness analysis
This patch replaces dynamic subreg_def tracking with a static computation of
zext_dst during register liveness analysis. The verifier now tracks the usage
of upper and lower register halves separately to infer whether a 32-bit
subregister definition requires explicit zero extension.
Link: https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 896bc5aaaaaff..e51cf5238f60a 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -15026,18 +14941,14 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
> if (insn->imm) {
> /* off == BPF_ADDR_SPACE_CAST */
> mark_reg_unknown(env, regs, insn->dst_reg);
> - if (insn->imm == 1) { /* cast from as(1) to as(0) */
> + if (insn->imm == 1) /* cast from as(1) to as(0) */
> dst_reg->type = PTR_TO_ARENA;
> - /* PTR_TO_ARENA is 32-bit */
> - dst_reg->subreg_def = env->insn_idx + 1;
> - }
[Severity: Critical]
Does this missing zero-extension for BPF_ADDR_SPACE_CAST allow out-of-bounds
arena access on architectures needing explicit zero-extension?
The patch removed the dynamic dst_reg->subreg_def = env->insn_idx + 1
assignment here. Since a BPF_ADDR_SPACE_CAST instruction is encoded as
BPF_ALU64 | BPF_MOV | BPF_X, the new bpf_insn_def32() function returns -1,
which evaluates zext_dst to false in the static liveness analysis.
Because check_alu_op() handles the cast but does not manually set
aux->zext_dst = true (unlike how it was handled in adjust_reg_min_max_vals()),
the subsequent zero-extension insertion pass is skipped.
On architectures like s390x, wouldn't this leave uninitialized garbage in the
upper 32 bits, allowing arbitrary kernel memory read/writes when the JIT adds
this register to the 64-bit arena base?
> } else if (insn->off == 0) {
> /* case: R1 = R2
> * copy register state to dest reg
> */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260802-static-zext-v3-0-3456b2604574@gmail.com?part=3
next prev parent reply other threads:[~2026-08-02 21:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 20:24 [PATCH bpf-next v3 0/5] bpf: infer zext_dst based on static register liveness analysis Eduard Zingerman
2026-08-02 20:24 ` [PATCH bpf-next v3 1/5] bpf: do not print a newline after disassembly in bpf_verbose_insn() Eduard Zingerman
2026-08-03 0:22 ` Quentin Monnet
2026-08-02 20:24 ` [PATCH bpf-next v3 2/5] bpf: track upper 32-bit register halves' liveness in compute_live_registers() Eduard Zingerman
2026-08-02 20:24 ` [PATCH bpf-next v3 3/5] bpf: infer zext_dst based on static register liveness analysis Eduard Zingerman
2026-08-02 21:07 ` sashiko-bot [this message]
2026-08-02 21:14 ` Eduard Zingerman
2026-08-02 20:24 ` [PATCH bpf-next v3 4/5] bpf: simplify the bpf_is_reg64() Eduard Zingerman
2026-08-02 21:26 ` sashiko-bot
2026-08-02 21:40 ` Eduard Zingerman
2026-08-02 20:24 ` [PATCH bpf-next v3 5/5] selftests/bpf: verify zext_dst annotations for various instructions Eduard Zingerman
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=20260802210741.D10C21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=eddyz87@gmail.com \
--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.