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

Helen Koike
2026-04-14T16:25:50Z

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@igalia.com/
>
> 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@gmail.com/
>
>> 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
> ...