GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: load-acquire into its own source register yields pointer type confusion

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

Impact

check_atomic_load() runs check_load_mem() before atomic_ptr_type_ok(). When a load-acquire targets its own source register, the load overwrites the source register's type, so the later pointer-type check no longer sees the original pointer and fails to reject ctx, pkt, flow_keys and sock sources. Because bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object survives into the loaded program: a load-acquire of __sk_buff->sk leaves the register typed PTR_TO_SOCK_COMMON_OR_NULL while holding unconverted struct sk_buff bytes. Past the NULL check that is pointer type confusion inside the kernel, not merely a kernel-memory leak - a credible local privilege-escalation primitive on any node where tenants or sidecars can load BPF programs, which on a Kubernetes GPU fleet includes CNI and observability agents.

Who can reach it

Local: any context able to load a BPF program with a BPF_ATOMIC load-acquire - CAP_BPF/CAP_SYS_ADMIN, or an unprivileged path where the fleet permits it. Authentication to the node is required; no remote vector.

What to do

Update to a stable kernel carrying the listed commits and reboot the node (drain first on GPU hosts - this is a verifier fix, not live-patchable in general). Until then, restrict who can call bpf() : keep unprivileged BPF disabled (kernel.unprivileged_bpf_disabled=1) and do not grant CAP_BPF or CAP_SYS_ADMIN to tenant workloads. No fixed distribution release is named in the record.

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.