Re: [PATCH bpf-next 2/5] bpf: track upper 32-bit register halves' liveness in compute_live_registers()

On Fri, 2026-07-31 at 19:18 +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issu=
e(s) to consider:
> - [Critical] Critical verifier bug in conditional jump liveness tracking =
causing missing zero-extensions.
> - [Low] Suboptimal liveness tracking for 32-bit conditional jumps causes =
unnecessary zero-extensions.
> --
>=20
> --- Patch [2]: [PATCH bpf-next 2/5] bpf: track upper 32-bit register halv=
es' liveness in compute_live_registers() ---
> commit 977deff7b46d8e36a957595add75da7e58a91c59
> Author: Eduard Zingerman <[email protected]>
>=20
> bpf: track upper 32-bit register halves' liveness in compute_live_registe=
rs()
>=20
> This commit extends compute_live_registers() to track upper and lower
> register halves' liveness separately. It uses 2 bits per register and
> updates compute_insn_live_regs() and kfunc call processing to infer usage
> based on BTF type sizes.
>=20
> > diff --git a/kernel/bpf/liveness.c b/kernel/bpf/liveness.c
> > index ff1e68cc4bd1c..c996b8a03e792 100644
> > --- a/kernel/bpf/liveness.c
> > +++ b/kernel/bpf/liveness.c
> [ ... ]
> > @@ -2174,17 +2228,15 @@ static void compute_insn_live_regs(struct bpf_v=
erifier_env *env,
> [ ... ]
> >  		default:
> >  			def =3D 0;
> >  			if (BPF_SRC(insn->code) =3D=3D BPF_K)
> >  				use =3D dst;
>=20
> [Severity: Low]
> Does this unconditionally apply the 64-bit mask for 32-bit jumps?
>=20
> Because dst is defined as the 64-bit mask, using it for BPF_JMP32
> conditional jumps incorrectly assumes the upper 32 bits are alive.
>=20
> Could this trigger unnecessary zero-extension instructions in the JIT?
>=20
> >  			else
> > -				use =3D dst | src;
> > +				use =3D dst | (code =3D=3D BPF_JMP32 ? src : src32);
>=20
> [Severity: Critical]
> Are the conditions and logic for tracking 64-bit jumps correct here?
>=20
> The variable code is derived using BPF_OP(), which masks out the class bi=
ts.
> Because of this, it will never equal the instruction class BPF_JMP32,
> making the condition always false.
>=20
> Additionally, if this were checking the class instead of code, it appears
> the branches of the ternary operator are reversed. As written, 64-bit jum=
ps
> always evaluate to src32, marking only the lower 32 bits of the source
> register as live.
>=20
> Could this cause the verifier to incorrectly omit the zero-extension flag
> for the preceding instruction that produced the source register, potentia=
lly
> leaving garbage data in the upper 32 bits during 64-bit comparisons?

These two issues are the same. So much for testing, need to fix this.

...