Re: [PATCH bpf-next 2/4] bpf: Simulate branches to prune based on range violations

[Paul Chaignon <paul.chaignon@gmail.com>]

On Tue, Mar 17, 2026 at 02:14:48PM +0800, Shung-Hsi Yu wrote:
> On Fri, Mar 13, 2026 at 11:54:43PM +0100, Paul Chaignon wrote:
> > From: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
> > 
> > This patch fixes the invariant violation warnings. These warnings
> 
> Nit: I would say this patch fix the invariant violation (minus the
> warning part), warning are gone after this, but that because we have
> fixed the caused of the warning.

I wondered about the same when writing this :) I thought it best to not
claim too much and be specific to the invariant violation we currently
warn about as technically there could be others.

> 
> > happen after we refine ranges & tnum based on an incorrectly-detected
> > branch condition. For example, the branch is always true, but we miss
> > it in is_branch_taken; we then refine based on the branch being false
> > and end up with incoherent ranges (e.g. umax < umin).
> ...
> > Fixes: 5f99f312bd3b ("bpf: add register bounds sanity checks and sanitization")
> 
> Following the thought above, I am uncertain about the fixes tag here.
> Commit 5f99f312bd3b surface the invariant violation as warning, but
> invariant violation still happens before that, we just don't catch it.
> That actual root cause would probably go even further back, but probably
> would be too much of a hassle to figure out. Maybe drop the tag?

Yep, that has been a question even for the previous invariant violation
fixes I've sent. On one hand, what is usually being reported as the bug
is the unecessary warning. But on the other hand, as you say, the
warning just surfaces an existing bug which we are fixing.

> 
> Put it in another way. If a tool uses this fixes tag to determine where
> this fix needs to be applied in stable, it would determine it is only
> needed for anything v6.8+, when 5f99f312bd3b is merged. But this patch
> probably should was be applied to stable kernel before v6.8, because
> IIUC invariant violation likely also happens there.

Yes, that's definitely a good point. We probably don't even want to
backport this to stable kernels (at least not until we've built more
confidence via syzbot). We'll drop the tag.

> 
> > Reported-by: syzbot+c950cc277150935cc0b5@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=c950cc277150935cc0b5
> > Co-developed-by: Paul Chaignon <paul.chaignon@gmail.com>
> > Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
> > Signed-off-by: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
> ...