All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eduard Zingerman" <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH RFC bpf-next 3/4] bpf: replace min/max fields with struct cnum{32,64}
Date: Tue, 21 Apr 2026 18:06:30 +0000	[thread overview]
Message-ID: <20260421180631.B0A44C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260421-cnums-everywhere-rfc-v1-v1-3-8f8e98537f48@gmail.com>

Sashiko AI review found 1 potential issue(s):
- [High] Incorrect range constructor used for BPF_JSLT (signed less-than), causing verifier soundness issues.
--

commit 1fb11732c3d626f4a1777699934aa05d07b7eb56
Author: Eduard Zingerman <eddyz87@gmail.com>

bpf: replace min/max fields with struct cnum{32,64}

This commit replaces the independent s64, u64, s32, and u32 min/max fields in
bpf_reg_state with two circular number fields, cnum64 and cnum32. It also
refactors how bounds deductions are performed and updates conditional branch
refinements to use circular numbers for set intersections.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 2e896f5d92a2d..90ed32f064650 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -15861,38 +15209,54 @@ static void regs_refine_cond_op(struct bpf_reg_state *reg1, struct bpf_reg_state

[ ... ]

>  	case BPF_JSLT:
>  		if (is_jmp32) {
> -			reg_set_srange32(reg1, reg_s32_min(reg1), min(reg_s32_max(reg1), reg_s32_max(reg2) - 1));
> -			reg_set_srange32(reg2, max(reg_s32_min(reg1) + 1, reg_s32_min(reg2)), reg_s32_max(reg2));
> +			lo32 = cnum32_from_urange(S32_MIN, reg_s32_max(reg2) - 1);
> +			hi32 = cnum32_from_urange(reg_s32_min(reg1) + 1, S32_MAX);
> +			reg1->r32 = cnum32_intersect(reg1->r32, lo32);
> +			reg2->r32 = cnum32_intersect(reg2->r32, hi32);
>  		} else {
> -			reg_set_srange64(reg1, reg_smin(reg1), min(reg_smax(reg1), reg_smax(reg2) - 1));
> -			reg_set_srange64(reg2, max(reg_smin(reg1) + 1, reg_smin(reg2)), reg_smax(reg2));
> +			lo = cnum64_from_urange(S64_MIN, reg_smax(reg2) - 1);
> +			hi = cnum64_from_urange(reg_smin(reg1) + 1, S64_MAX);
> +			reg1->r64 = cnum64_intersect(reg1->r64, lo);
> +			reg2->r64 = cnum64_intersect(reg2->r64, hi);
>  		}
>  		break;

Are the unsigned range constructors cnum32_from_urange() and
cnum64_from_urange() correct to use here for a signed less-than comparison?

Passing S32_MIN and S64_MIN into the unsigned constructors might cause them to
evaluate min > max, resulting in invalid or empty ranges being intersected with
the registers. Should these use cnum32_from_srange() and cnum64_from_srange()
like the BPF_JSLE case does?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260421-cnums-everywhere-rfc-v1-v1-0-8f8e98537f48@gmail.com?part=3

  parent reply	other threads:[~2026-04-21 18:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 10:28 [PATCH RFC bpf-next 0/4] bpf: replace min/max fields with struct cnum{32,64} Eduard Zingerman
2026-04-21 10:28 ` [PATCH RFC bpf-next 1/4] bpf: representation and basic operations on circular numbers Eduard Zingerman
2026-04-21 11:16   ` bot+bpf-ci
2026-04-21 17:18   ` sashiko-bot
2026-04-21 17:45     ` Eduard Zingerman
2026-04-23 22:51     ` Eduard Zingerman
2026-04-21 10:28 ` [PATCH RFC bpf-next 2/4] bpf: use accessor functions for bpf_reg_state min/max fields Eduard Zingerman
2026-04-21 10:28 ` [PATCH RFC bpf-next 3/4] bpf: replace min/max fields with struct cnum{32,64} Eduard Zingerman
2026-04-21 11:16   ` bot+bpf-ci
2026-04-21 16:23   ` Alexei Starovoitov
2026-04-21 16:48     ` Eduard Zingerman
2026-04-21 17:16       ` Alexei Starovoitov
2026-04-21 17:20         ` Eduard Zingerman
2026-04-21 18:06   ` sashiko-bot [this message]
2026-04-21 18:31     ` Eduard Zingerman
2026-04-21 10:28 ` [PATCH RFC bpf-next 4/4] selftests/bpf: new cases handled by 32->64 range refinements Eduard Zingerman
2026-04-21 16:10 ` [PATCH RFC bpf-next 0/4] bpf: replace min/max fields with struct cnum{32,64} Alexei Starovoitov
2026-04-21 16:33   ` Eduard Zingerman
2026-04-21 17:14     ` Alexei Starovoitov
2026-04-21 23:45 ` Eduard Zingerman
2026-04-22 14:50 ` Yazhou Tang
2026-04-22 15:03   ` Alexei Starovoitov
2026-04-22 15:32     ` Yazhou Tang
2026-04-22 16:13       ` Alexei Starovoitov
2026-04-23 11:23         ` shenghao yuan
2026-04-22 19:05   ` Eduard Zingerman
2026-04-23 11:45     ` shenghao yuan
2026-04-23 14:18       ` Yazhou Tang

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=20260421180631.B0A44C2BCB0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=sashiko@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.