Re: [PATCH 1/2] bpf: deduce_bounds_64_from_32 tightening with circular range logic

[Helen Koike]

Hi Shung-Hsi Yu,


Thanks for your reply,

On 4/14/26 5:26 AM, Shung-Hsi Yu wrote:
> Hi Helen,
>
> On Fri, Apr 10, 2026 at 09:40:27AM -0300, Helen Koike wrote:
> ...
> > This is a follow-up from discussion:
> >    https://lore.kernel.org/all/7fb97184-baaa-4639-a0b9-ac289bf2e54d@xxxxxxxxxx/
>
> Base on the original thread, I see that motivation of the patchset came
> from a Syzkaller reported issue[1]. Can you try to run the reproducer
> again and see if you can still get it to reproduce on the bpf-next tree?

I just tested on bpf-next/master ("71b500afd2f7") and I couldn't 
reproduce the issue from Syzbot anymore. It seems that the branch 
causing the issue is pruned now, fixing the error in that case.

But I still get the failures of the kselftests from patch 2/2:

    * verifier_bounds/deduce64_from_32_block_change:FAIL
    * verifier_bounds/deduce64_from_32_block_change_signed:FAIL
    * 
verifier_bounds/deduce64_from_32_block_change_conservative_signed:FAIL
    * verifier_bounds/deduce64_from_32_wrapping_32bit:FAIL


How do you suggest we should proceed?

> I tried it myself, but I somehow can't get the bpf-next kernel to boot
> when KMSAN enabled.
>
> Given check_cond_jmp_op showed up the the kernel stack of the report,
> I'm guessing it might have be resolved with Paul's "Fix invariant
> violations and improve branch detection" patchset[2].

Thanks for the pointer!

> Side note: were you able to figure out why we get "KMSAN: uninit-value"
> within reg_bounds_sanity_check() in the original Syzkaller report[1]
> with the follow call?
>
> 	verifier_bug(env, "REG INVARIANTS VIOLATION (%s): %s u64=[%#llx, %#llx] "
> 		     "s64=[%#llx, %#llx] u32=[%#x, %#x] s32=[%#x, %#x] var_off=(%#llx, %#llx)",
> 		     ...);

Unfortunately no. I investigated a bit but I didn't continue :(


Thanks,
Helen

> 1: https://syzkaller.appspot.com/bug?id=6f35b4962ae3653e4190d0ff3e30b882ebe86755
> 2: https://lore.kernel.org/bpf/cover.1775142354.git.paul.chaignon@xxxxxxxxx/
>
> > I didn't tag this as v2 since it is a completely different
> > implementation.
> >
> > I did do an implementation[1] without circular range logic, by using
> > if/elses blocks, but it feels I'm always missing a corner case and using
> > circular range logic feels safer.
> >
> > Eduard, I didn't use the exact code you pointed, since it seems it is
> > covered by your RFC, so I used the logic just for this case while your
> > RFC doesn't move forward.
> >
> > Please let me know what you think.
> >
> > [1]
> > https://github.com/helen-fornazier/linux/commits/bpf-min-max-if-else-solution/
> > (3 last commits)
> >
> > Thanks,
> > Helen
> ...