Re: [PATCH bpf-next v2 1/2] bpf: reject pointer operands for 32-bit recurrences/latches

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2026-10-21 at 22:22 +0000, Alexei Starovoitov wrote:
> On Wed, Oct 21, 2026 at 11:56 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > Fixes: df4761bd441c ("bpf: Support 32-bit linear scalar evolution")
> 
> sorry, few commits were dropped from bpf-next.
> It's 32e962577d2d now.

Uh-oh.

> > +			/* 32-bit ALU operations on pointers convert them to scalars */
> > +			if (coefs.zext32 && reg->type != SCALAR_VALUE)
> > +				goto cant_widen;
> 
> le64 does the same without zext32.
> 
>      r7 = map_value, r1 = 0
>   l: r7 = le64 r7
>      if r7 < 100 goto out
>      if r7 > 1000 goto out
>      r7 += 8
>      r1 += 1
>      if r1 != 4 goto l
> 
> On little endian transfer() treats le64 as a nop, so r7 at the header
> is (linear r7 8), while check_alu_op() makes it an unknown scalar.
> At the backedge r7 is a scalar 108..1008 and bpf_clamp_scev_regs()
> intersects it with 0..24, the offsets of map_value at the loop entry:
>   verifier bug: scev clamp produced empty range for r7

I'm going to drop intersection from clamping, testing it now.

> Should bpf_clamp_scev_regs() skip the reg when
> 	entry_reg->type != reg->type
> ?

Not clamping would be bad, as the induction variable would get a range
outside of it's possible in-loop range on a backedge.
For this particular case, I think le64 should just stay a separate
expression, not a noop. E.g. during transfer() "r7 = (le64 r7)",
hence no SCEV would be computed for it.
I'll check if there are other operations that have similar effect.

My take is that this is a separate issue.
I can pack the fix with this patch as a patch-set, if you'd like that.