Re: [PATCH bpf-next 1/2] bpf: support 32-bit linear scalar evolution

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-10-20 at 21:00 +0000, Alexei Starovoitov wrote:
> On Tue, Oct 20, 2026 at 04:35 AM bot+bpf-ci@kernel.org <bot+bpf-ci@kernel.org> wrote:
> > > +	if (!scev_value_compatible(env, st, &initial_val, &bound_val))
> > > +		return false;
> > 
> > For a pointer-vs-pointer JMP32 latch (allowed for privileged programs, since
> > check_cond_jmp_op() only rejects pointer comparisons when !allow_ptr_leaks),
> > can the computed max_header_count end up smaller than the real number of
> > iterations?  bpf_widen_scev_regs() and bpf_clamp_scev_regs() then bound the
> > induction pointer's range with that count, and the memory access checks
> > inside the loop depend on it being a true upper bound.
> > 
> > Would it make sense to return false here when latch->jmp32 is set and either
> > initial_val.ptr_reg or bound_val.ptr_reg is >= 0?  zext32 latches cannot
> > involve pointers, because ALU32 on pointers is rejected.
> 
> Yes. Seems like a real bug.
> 
>   r1 = map_value + 0, r2 = map_value + 56
>   l: r1 += 8; if w1 <= w2 goto l
> 
> max_header_count is 8 and r1 is clamped to 0..56. If the low 32 bits
> of r2 are 0xfffffff8 then w1 wraps to 0 and the latch stays true,
> so r1 walks past the map value.
> 
> pls fix in a followup.

Yes, and another complain about clamping and possibly dead states.
I'll send follow up for pointers today. For clamping need to think a bit.