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 15:50 -0700, Eduard Zingerman wrote:
> 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:

...

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

Actually, I don't think there is anything to fix:
- check_alu_op() errors out if le64 is applied to a pointer.
- (linear r7 8) means that every path over the loop body
  is guaranteed to construct the linear equation.

Meaning that le64 would remain visible to the main verification pass
and would be rejected.

I'll re-spin these two patches as a part of bigger series with a
correct fixes tag but otherwise unchanged.