Linux kernel BPF verifier: missed zero-extension marking lets a loaded program inject arbitrary register upper halves

Impact

The verifier's tracking of which 32-bit operations need an explicit zero-extension depended on per-path register state, so on one verification path a register definition could lose its zext_dst mark while another path relies on the upper half being cleared. A program accepted by the verifier can then carry an attacker-chosen value in a register's upper 32 bits, which is the classic starting point for turning a verified-safe BPF program into out-of-bounds kernel access and local privilege escalation. The fix recomputes this statically as part of live-register analysis. The practical reach is narrow and worth stating plainly: the broken zero-extension semantics matter where the JIT relies on the verifier emitting the extension, which the commit message identifies as s390. On the x86-64 and arm64 nodes that make up essentially every GPU fleet the exposure is far lower, and it is nil where unprivileged BPF is disabled. Where it does apply, a compromised root-equivalent kernel on a GPU node means any co-tenant isolation on that node is gone, and the remedy is a reboot of a node that is expensive to drain.

Who can reach it

Local only. The attacker needs to be able to load a BPF program - CAP_BPF/CAP_SYS_ADMIN in the init namespace, or an unprivileged context where kernel.unprivileged_bpf_disabled is off. A tenant GPU pod cannot do this under a default-restricted runtime; a privileged observability or networking agent on the node can.

What to do

Take the stable-kernel update containing commit 7ce090afbf72 from your distribution, then drain and reboot each node - there is no runtime mitigation for a verifier bug. Until the reboot window, set kernel.unprivileged_bpf_disabled=1 and keep CAP_BPF out of tenant workloads, which removes the attack path for everything but already-privileged node agents. Treat it as low priority on x86-64 and arm64 fleets and roll it with your normal kernel cadence; prioritize it on s390 systems.

References

Related entries

• drm/vmwgfx: unvalidated pitch in cursor snooping allows out-of-bounds reads in a VMware guestCVE-2026-99002 · Linux kernel drm/vmwgfx (cursor snooping, unvalidated userspace pitch)High
• Linux net/smc: use-after-free on the CLC socket in smc_getname during link-group terminationCVE-2026-99032 · Linux kernel net/smc (smc_getname clcsock lifetime)High
• KVM SEV: unlocked set_page_dirty on get_user_pages_fast pages during guest memory populationCVE-2026-99177 · Linux kernel KVM SEV (sev_gmem_post_populate guest-memory population)High
• Linux kernel io_uring/waitid: repeated failed cancellations wrap the reference counter and double-complete a requestCVE-2026-99227 · Linux kernel io_uring waitid (31-bit cancel reference counter wrap)High
• Linux kernel io_uring/waitid: use-after-free when the wake handler clears ->head before owning the requestCVE-2026-99231 · Linux kernel io_uring waitid (use-after-free via ->head cleared before ownership)High
• Linux kernel sched_ext: DSQ consume and move paths operate on a task still being dispatchedCVE-2026-99269 · Linux kernel sched_ext (DSQ consume/move racing SCX_OPSS_DISPATCHING)High