CVE-2026-98869: bpf: Infer zext_dst based on static register liveness analysis

In the Linux kernel, the following vulnerability has been resolved:

bpf: Infer zextdst based on static register liveness analysis

As reported in the thread [1], the verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct semantics of 32-bit operations on s390 architecture.

According to BPF semantics, operation w1 += 1 is supposed to zero extend the upper half of the register r1. On s390 the JIT relies on the verifier emitting explicit zero extension before such operations.

The verifier attempts to minimize the amount of zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used. Previously such tracking worked as follows:

- bpfregstate->subregdef field was set by docheckinsn() for each operation defining lower but not the upper halves of the register. - Whenever an operation reading the whole register was verified, the verifier checked register's subregdef and set bpfinsnauxdata->zextdst flag as true via a call to markinsnzext() function. - After the verification was complete, a special pass bpfoptsubregzextlo32rndhi32() extended 32-bit operations with bpfinsnauxdata->zextdst set as true by adding explicit zero extension.

Note that the logic above relies on bpfregstate->subregdef, which is a property of a current verifier state. Before the commit [2] two additional steps happened:

- The verifier tracked upper and lower register halves' liveness as flags REGLIVEREAD{32,64} in bpfregstate->live. - The function propagateliveness() called markinsnzext() in order to transfer the knowledge about which registers have their upper halves alive (and thus might require zero extension).

The commit [2] removed the two steps described above, hence making possible a situation like below:

- The register's upper half is set and is used on some verification path P1 and the register happens not to be marked as precise. - The checkpoint C is created while processing some instruction between register initialization and usage. - On some other verification path P2 the register's upper half is not initialized and that path ends hitting the checkpoint C. - In such a case the register's initialization on path P2 would lack zextdst mark, making it possible for the program to inject an arbitrary value in the register's upper half.

This commit replaces subregdef based logic with computing zextdst statically, as a part of the bpfcomputeliveregisters() analysis:

- The analysis now tracks usage of upper and lower halves of the registers separately. - If some instruction defines a 32-bit subregister, but not the whole register, and the upper half of the register is alive after that instruction, the instruction is marked as zextdst.

There is one notable drop in precision: whenever a BPF subprogram is called, all 64 bits of parameter registers are presumed to be used. The assumption is that such a drop in precision would not inflict a noticeable performance penalty.

[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness")