Re: [PATCH v2 bpf-next 3/6] bpf: Exit early if reg_bounds_sync gets invalid inputs

Shung-Hsi Yu
2026-03-23T12:12:43Z

On Fri, Mar 20, 2026 at 05:49:30PM +0100, Paul Chaignon wrote:
> From: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
>
> In the subsequent commit, to prune dead branches we will rely on
> detecting ill-formed ranges using range_bounds_violations()
> (e.g., umin > umax) after refining register bounds using
> regs_refine_cond_op().
>
> However, reg_bounds_sync() can sometimes "repair" ill-formed bounds,
> potentially masking a violation that was produced by
> regs_refine_cond_op().
>
> This commit modifies reg_bounds_sync() to exit early if an invariant
> violation is already present in the input.
>
> This ensures ill-formed reg_states remain ill-formed after
> reg_bounds_sync(), allowing simulate_both_branches_taken() to correctly
> identify dead branches with a single check to range_bounds_violation().
>
> Suggested-by: Eduard Zingerman <eddyz87@gmail.com>
> Signed-off-by: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>

Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>

Thought given reg_bounds_sync() is used if various different places, I
wonder how this will affect current syzbot reporting. In comparison the
rest of the patchset seems to try to preserve current behavior.

Being nosey, I also look at the Sashiko review[1], which gave the
following review:

Does returning early here expose invalid bounds to
reg_bounds_sanity_check()?
When regs_refine_cond_op() produces overlapping bounds for logically dead
branches (e.g., umin > umax), reg_bounds_sync() previously repaired them.
With this early exit, the invalid bounds remain.
Will the subsequent call to reg_bounds_sanity_check() detect this violation
and trigger a kernel warning via verifier_bug() and BPF_WARN_ONCE?
Additionally, since reg_bounds_sanity_check() handles failures by marking
the register as unbounded, could this cause the verifier to explore dead
branches with unconstrained registers and falsely reject valid programs?
While this is resolved in the subsequent commit "bpf: Simulate branches to
prune based on range violations", could this intermediate state break
git bisectability?

Given if we get invalid bounds in reg_bounds_sync() to begin with, then
there is no guarantee that what the BPF verifier ended up with can be
trusted at all, so returning early shouldn't introduce new safety issue,
and the rest about falsely rejecting valid program doesn't seem like a
concern, too, for similar reason.

1: https://sashiko.dev/#/patchset/cover.1774025082.git.paul.chaignon%40gmail.com

...