GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel bpf/sockmap: SKB refcount race gives use-after-free in the backlog worker

CVSS 7.8CVE-2023-53836Kernel, userspace & hypervisorcurated

Impact

A sockmap-attached socket can hand an SKB to the ingress message queue and let userspace consume and free it while the sk_psock_backlog worker still holds the pointer, producing a use-after-free dequeued in kernel workqueue context (observed as a general protection fault in skb_dequeue). Sockmap is used by Cilium and other eBPF dataplanes that commonly run on GPU clusters, so the vulnerable path is live on nodes using eBPF socket acceleration. A local attacker able to load or exercise sockmap programs gets kernel-memory corruption on a shared node; at minimum it is a host crash that takes every tenant pod with it.

Who can reach it

Local, requires the ability to drive a sockmap-attached socket - in practice a privileged dataplane component or a user with CAP_BPF/CAP_NET_ADMIN, or any workload whose traffic traverses an existing sockmap. Not remotely reachable on its own.

What to do

Update to a stable kernel containing the skb_get() fix (commits 65ad600b9bde, 923877254f00, a454d84ee20b, e6b5e47adb91) and reboot each node. As an interim mitigation, disable sockmap-based socket acceleration in the CNI (for Cilium, the socket-level load balancing / sockops features) - this costs throughput but removes the path 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.