BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 4/5] bpf: simplify the bpf_is_reg64()
Date: Sun, 02 Aug 2026 14:40:59 -0700	[thread overview]
Message-ID: <20e990a0389bea4acb526dd7756699a95b0779b9.camel@gmail.com> (raw)
In-Reply-To: <20260802212700.A46CF1F000E9@smtp.kernel.org>

On Sun, 2026-08-02 at 21:26 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] bpf_is_reg64() fails to identify BPF_ADDR_SPACE_CAST operations with imm == 1U << 16 as 32-bit when the arena has BPF_F_NO_USER_CONV set, leading to missing zero-extension and possible sandbox escape.
> - [Critical] Unconditional overwrite of `zext_dst` destroys manual overrides for `PTR_TO_ARENA` arithmetic, leading to missing zero-extensions and arbitrary kernel memory access.
> --
> 
> --- Patch [4]: [PATCH bpf-next v3 4/5] bpf: simplify the bpf_is_reg64() ---
> commit 4ece654ab9bc1fb0f5d2f2cc247cae7c94f2cb89
> Author: Eduard Zingerman <eddyz87@gmail.com>
> 
> bpf: simplify the bpf_is_reg64()
> 
> This commit simplifies bpf_is_reg64() by removing unused parameters,
> removing BPF_JMP instructions handling, and streamlining conditions. It
> also moves the function to kernel/bpf/fixups.c.
> 
> > diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
> > index 6125598d16a84..7b3510d46b377 100644
> > --- a/kernel/bpf/fixups.c
> > +++ b/kernel/bpf/fixups.c
> 
> [ ... ]
> 
> > @@ -44,6 +44,49 @@ static int insn_def_regno(const struct bpf_insn *insn)
> >  	}
> >  }
> >  
> > +/*
> > + * For use only in combination with insn_def_regno() >= 0.
> > + * Returns TRUE if the destination register operates on 64-bit,
> > + * otherwise return FALSE.
> > + */
> > +static bool bpf_is_reg64(struct bpf_insn *insn)
> > +{
> > +	u8 class = BPF_CLASS(insn->code);
> > +	u8 mode = BPF_MODE(insn->code);
> > +	u8 size = BPF_SIZE(insn->code);
> > +	u8 op = BPF_OP(insn->code);
> > +	bool mode_mem;
> > +
> > +	/* subregister endiness swap */
> > +	if ((class == BPF_ALU || class == BPF_ALU64) && op == BPF_END && insn->imm != 64)
> > +		return false;
> > +
> > +	/* w0 += 1 */
> > +	if (class == BPF_ALU && op != BPF_END)
> > +		return false;
> > +
> > +	/* cast from as(1) to as(0), PTR_TO_ARENA is 32-bit */
> > +	if (insn->code == (BPF_ALU64 | BPF_MOV | BPF_X) &&
> > +	    insn->off == BPF_ADDR_SPACE_CAST && insn->imm == 1)
> > +		return false;
> 
> [Severity: Critical]
> Does this logic miss identifying BPF_ADDR_SPACE_CAST operations with
> imm == 1U << 16 as 32-bit?
> 
> If the arena has BPF_F_NO_USER_CONV set, bpf_do_misc_fixups() rewrites
> all BPF_ADDR_SPACE_CAST instructions (including imm == 1U << 16) into
> a 32-bit MOV to explicitly clear the upper 32 bits.

I think this is a pre-existing bug.
I'll add a test.

...

> > +/*
> > + * Return the 32-bit subregister defined by INSN, or -1 if INSN does not
> > + * explicitly define a 32-bit value.
> > + */
> > +int bpf_insn_def32(struct bpf_insn *insn)
> > +{
> > +	int dst_reg = insn_def_regno(insn);
> > +
> > +	if (dst_reg < 0 || bpf_is_reg64(insn))
> > +		return -1;
> 
> [Severity: Critical]
> Would this unconditional behavior inadvertently overwrite manual overrides
> for PTR_TO_ARENA arithmetic?

No it won't.
convert_ctx_access() downgrades those operations to BPF_ALU.
There is also a test to check this.

...

  reply	other threads:[~2026-08-02 21:41 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
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 [this message]
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=20e990a0389bea4acb526dd7756699a95b0779b9.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --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