GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF sockmap: use-after-free on the af_unix peer when a socket closes during iteration

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

Impact

A BPF iterator program that updates a sockmap can race unix_release_sock(): the iterator reads unix_peer(sk), the closing path clears the peer pointer and drops its reference, and the iterator then calls sock_hold() on freed memory. The KASAN report in the record shows a confirmed slab-use-after-free write of 4 bytes in unix_stream_bpf_update_proto reached through sock_map_update_elem from a BPF iterator - this one is demonstrated, not theoretical. Sockmap and af_unix iteration are what eBPF service meshes and socket-redirect datapaths do, so the exposed component on a GPU cluster is the networking agent running on every node rather than the tenant workload. A controlled write into freed slab memory from a privileged kernel context is the shape that leads to host compromise; the fix takes the state lock so the iterator always sees a stable socket.

Who can reach it

Local. Requires the ability to load and run BPF iterator programs that update a sockmap - CAP_BPF/CAP_SYS_ADMIN, in practice the CNI, service mesh or observability agent. Racing it needs a concurrent af_unix close, which an attacker on the same node controls.

What to do

Patch to a fixed stable or distribution kernel and reboot. Red Hat tracks it for RHEL 6 through 10. If you run an eBPF-based CNI or mesh that uses sockmap with af_unix, that agent is the exposure, so the kernel reboot is the only real fix - disabling the agent is usually worse than the bug. Drain and reboot per node.

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.