GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: inconsistent ADD_CONST base ids let unsafe state pruning succeed

CVSS 7.8CVE-2026-53081Kernel, userspace & hypervisorcurated

Impact

When regsafe() compared two scalar registers carrying BPF_ADD_CONST, check_scalar_ids() mapped the compound id but never verified that the stripped base ids agreed with existing mappings. An attacker can construct two verifier states - old with R3 = R2 + 10, current with R3 = R4 + 10 from an unrelated base - and the idmap records two independent entries without noticing the conflict, so state pruning wrongly succeeds. That means the verifier accepts a program whose register relationships it has not actually proven, which is the standard route to out-of-bounds kernel reads and writes from a BPF program. Verifier soundness bugs deserve more attention than a generic local 7.8 suggests: the verifier is the only thing standing between a loaded program and arbitrary kernel memory, and on nodes where BPF loading is delegated to agents or tenants it is a trust boundary, not an implementation detail.

Who can reach it

Local. Requires the ability to load a crafted BPF program - CAP_BPF or CAP_SYS_ADMIN, or unprivileged BPF where it is still enabled. The exploit is the program itself; no race and no special hardware.

What to do

Patch to a fixed stable or distribution kernel and reboot; the fix adds a check_ids() call on the stripped base ids. Red Hat tracks it for RHEL 6 through 10. In the interim, confirm unprivileged BPF is off (kernel.unprivileged_bpf_disabled=1) and that CAP_BPF is held only by agents you control - that closes the realistic path for most clusters without a reboot.

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.