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

[Shung-Hsi Yu]

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

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)",
		     ...);

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