GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: stale register bounds let an LSM-hook retval load bypass memory-safety checks

CVSS 8.8CVE-2026-72111Kernel, userspace & hypervisorcurated

Impact

When the verifier narrows an LSM hook return value it called __mark_reg_s32_range(), which intersects with the register's existing bounds instead of replacing them. A register carrying stale bounds from a prior instruction can end up with a range narrower than reality, so the verifier believes it knows an exact value that differs from what is loaded at runtime. That verifier/runtime mismatch is the classic route to defeating BPF memory-safety checks and reading or writing kernel memory from a loaded program - in practice host root from whoever can load the program. On a GPU fleet this matters wherever BPF program loading is reachable by anything other than the node's administrators: observability agents, CNI dataplanes, and any pod granted CAP_BPF.

Who can reach it

Local actor able to load a BPF program that performs a context load of an LSM hook return value - root, CAP_BPF/CAP_SYS_ADMIN, or a container granted those capabilities. Not reachable without BPF load privileges, and unreachable on kernels built without BPF LSM.

What to do

Update to a stable kernel with the mark_reg_unknown() reset in the is_retval path (four stable commits linked) and reboot each node; a verifier change ships in the kernel image. In the meantime, the exposure is governed by who may load BPF: denying CAP_BPF and CAP_SYS_ADMIN to tenant pods closes it without maintenance. The record carries no vendor advisory with fixed version strings.

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.