Re: [PATCH stable 6.6.y v2 0/3] bpf: backport scalar not-equal tracking fixes

[Zhenzhong Wu]

Hi Shung-Hsi,

> More importantly, 'bpf: make the verifier tracks the "not equal" for
> regs' does not address root cause of the issue, it merely mask the issue
> by making the two states different enough that the two is no longer
> equal, which works for the Rust specific case you have, but won't work
> if the value was slightly different (e.g. "r0 == 1" followed by "r0 !=
> 1").

Thanks for spelling this out. I now see that I did not fully
understand the point behind your suggested bpf-next-with-d028-reverted
check.

I was treating the not-equal refinement and the linked-scalar precision
issue as two ways to break the same failure chain, and chose the
d028-based path because it was smaller and easier for me to reason
about. With the `r0 == 1` variant, it became clear to me that this only
fixes the zero-valued branch shape from my original reproducer, while
the underlying linked-scalar pruning issue remains.

> Could you give backporting the full "bpf: track find_equal_scalars history on
> per-instruction level" series[3] a try? For 6.6 it should be doable, and
> hopefully for 6.1, too, but not too sure about earlier ones. If you prefer I
> work on it I can also give it a try later this week.

Sure, I will prepare v3 based on that series for 6.6.y, and then work
on the 6.1.y adaptation separately.

I tried applying the series starting from 6.1.y and still hit some
issues that need adaptation. 5.15.y and 5.10.y appear to need more
surrounding verifier changes, so they may be harder, but I will still
try to work through them. If I run into anything I am unsure about, I
will raise it earlier.

> As for the selftest, it would need to be send separately and by itself
> to bpf-next, and picked up there, before it can be backported to stable.
> I suggest you look at [4] and have your test placed similarly, and
> mention that your test specifically test a Rust/Aya pattern.

Thanks, I will send the selftest to bpf-next separately. I will also
change the test to use the `r0 == 1` / `r0 != 1` shape, so it covers
the broader linked-scalar pruning issue instead of only the original
zero-valued case.

Thanks again for the detailed explanation. I have only recently started
digging into the verifier implementation details, so this was very helpful!

BR,
Zhenzhong

On Mon, Jun 8, 2026 at 6:11 PM Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote:
>
> Hi Zhenzhong,
>
> On Mon, Jun 08, 2026 at 01:09:55AM +0800, Zhenzhong Wu wrote:
> > Hi,
> >
> > This series backports two BPF verifier scalar range-tracking fixes to
> > 6.6.y and adds a selftest. It fixes a verifier state-pruning issue where
> > an impossible linked-scalar path can be kept while the real success path is
> > pruned.
> ...
> >   15: (85) call bpf_get_func_ret#184    ; R0_w=scalar() fp-8_w=mmmmmmmm
> >   16: (79) r7 = *(u64 *)(r10 -8)        ; R7_w=scalar() R10=fp0
> >   17: (15) if r0 == 0x0 goto pc+1       ; R0_w=scalar()
> >   18: (bf) r7 = r0                      ; R0=scalar(id=1) R7=scalar(id=1)
> >   19: (55) if r0 != 0x0 goto pc+6       ; R0=0
> >   20: (67) r7 <<= 32                    ; R7_w=0
> >   21: (77) r7 >>= 32                    ; R7_w=0
> >   22: (b7) r1 = 1                       ; R1_w=1
> >   23: (55) if r7 != 0xf goto pc+1
> ...
> > I also checked bpf-next: bpf-next passes even when the d028f87517d6 JNE
> > refinement is reverted, because newer kernels also have the later
> > 4bf79f9be434e ("bpf: Track equal scalars history on per-instruction level")
> > precision-tracking change. I did not use 4bf79f9be434e as the stable
> > backport base because it is a broader jmp_history/precision-tracking change
> > for linked scalars. For 6.6.y this series keeps the smaller stable backport
> > path that directly follows the bisected fix: preserve scalar bounds after
> > conditional refinement, then add the not-equal range refinement in the older
> > reg_set_min_max() layout.
> ...
>
> To be honest I have not figure everything out yet, but I really much
> prefer we backport commit 4bf79f9be434e ("bpf: Track equal scalars
> history on per-instruction level") to address the issue instead. While
> 'bpf: make the verifier tracks the "not equal" for regs' itself is
> self-contained and reasonable, "bpf: drop knowledge-losing
> __reg_combine_{32,64}_into_{64,32} logic" comes from a much larger
> series[1], and taking that out of context seems rather risky[2].
>
> More importantly, 'bpf: make the verifier tracks the "not equal" for
> regs' does not address root cause of the issue, it merely mask the issue
> by making the two states different enough that the two is no longer
> equal, which works for the Rust specific case you have, but won't work
> if the value was slightly different (e.g. "r0 == 1" followed by "r0 !=
> 1").
>
> The root cause to the problem have been stated by you already, it is:
>
> > The relevant pruning point is that regsafe()/states_equal() accepted the
> > real success-path state against an earlier cached state where r0 was an
> > imprecise scalar and r7 constraints were loose enough to cover the current
> > r7.
>
> Looking at the verifier log you have, in the impossible path we have
> r0.id == r7.id from instruction 18, where as the real success path (that
> skips instruction 18) does not have that relationship, thus the two
> should be considered different, and that seems just what "bpf: track
> find_equal_scalars history on per-instruction level" solves by having
> the correct precise mark.
>
> Could you give backporting the full "bpf: track find_equal_scalars history on
> per-instruction level" series[3] a try? For 6.6 it should be doable, and
> hopefully for 6.1, too, but not too sure about earlier ones. If you prefer I
> work on it I can also give it a try later this week.
>
> As for the selftest, it would need to be send separately and by itself
> to bpf-next, and picked up there, before it can be backported to stable.
> I suggest you look at [4] and have your test placed similarly, and
> mention that your test specifically test a Rust/Aya pattern.
>
>
> Thanks,
> Shung-Hsi
>
> 1: https://lore.kernel.org/r/20231102033759.2541186-1-andrii@xxxxxxxxxx
> 2: https://lore.kernel.org/bpf/20260601182508.29C811F00893@xxxxxxxxxxxxxxx/
> 3: https://lore.kernel.org/bpf/20240718202357.1746514-1-eddyz87@xxxxxxxxx/
> 4: https://lore.kernel.org/bpf/20240718202357.1746514-4-eddyz87@xxxxxxxxx/
>
> [...]