GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: atomic-fetch precision gap lets equivalent-looking states be pruned

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

Impact

backtrack_insn treated a BPF_STX with BPF_ATOMIC|BPF_FETCH as if the source register were input only, when it is also a destination receiving the old memory value. Precision never propagates to the stack slot, so the slot is not marked precise and the verifier's path pruning can call two states equivalent that actually differ. A program that should have been rejected gets accepted, which is the standard route to arbitrary kernel memory access from verified BPF. Reaching it requires the ability to load BPF programs, so on a GPU node the exposure is tenants given privileged pods or CAP_BPF for eBPF observability sidecars, not ordinary workloads. NVD rates it 7.8, local only.

Who can reach it

A local user able to load eBPF programs: CAP_BPF or CAP_SYS_ADMIN on the host or in a privileged container, or any local user if kernel.unprivileged_bpf_disabled is 0. No remote path.

What to do

Take a stable kernel containing the linked fix and reboot the node, draining GPU workloads first - there is no live-patch path for verifier logic. As an interim mitigation set kernel.unprivileged_bpf_disabled=1 and stop granting CAP_BPF or CAP_SYS_ADMIN to tenant pods; that removes the precondition entirely for multi-tenant nodes.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-43009https://git.kernel.org/stable/c/179ee84a89114b854ac2dd1d293633a7f6c8dac1https://git.kernel.org/stable/c/7ffbe45b1d227e24659998a91cfd4c27af457e71https://git.kernel.org/stable/c/ea150ffa9fc9f78c5cf22e1f7b06b6d016b1017c

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.