GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: mis-tracked rX += rX delta lets a program diverge from its verified bounds

CVE-2026-53092Kernel, userspace & hypervisorcurated

Impact

For rX += rX the verifier modifies dst_reg in place and then reads the already-modified value as the source when computing the delta, so sync_linked_regs() propagates a wrong delta to linked registers. The result is a verifier-versus-runtime mismatch: the kernel believes a register is bounded differently than it actually is at run time, which is the standard starting point for turning a loadable BPF program into an arbitrary kernel read and write. On a shared GPU node that means local privilege escalation and a plausible container escape for anything allowed to load BPF - which in practice includes node-level observability and networking agents, and any tenant pod granted CAP_BPF or CAP_SYS_ADMIN. Exploitation is local only; there is no remote path.

Who can reach it

A local user or container that can load a BPF program. On distributions that keep kernel.unprivileged_bpf_disabled set, that requires CAP_BPF or CAP_SYS_ADMIN rather than being open to any unprivileged process. Authentication to the node (or a pod on it) is required.

What to do

Update to a kernel that skips the src_reg == dst_reg case; Red Hat tracks this at the linked advisory and the fix is in the listed stable commits. Kernel change, so drain and reboot each node, or take a vendor livepatch if your distribution offers one. Until then, confirm kernel.unprivileged_bpf_disabled is set and audit which pods and node agents actually hold CAP_BPF or CAP_SYS_ADMIN - most do not need it.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.