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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

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.