GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sockmap: use-after-free of sk->sk_socket when an AF_UNIX peer is orphaned

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

Impact

unix_stream_sendmsg() calls the peer's ->sk_data_ready() after dropping unix_state_lock(). The sender holds a refcount on the peer socket but that does not stop the peer's sock_orphan(), so sk->sk_socket can be freed after an RCU grace period while sk_psock_verdict_data_ready() is still dereferencing it - a KASAN slab-use-after-free reported by syzbot on an ordinary sendmsg() path. Sockmap is not an exotic feature on these fleets: it is what BPF-based service mesh and socket-redirect datapaths use, so the code is live on nodes running Cilium-style networking. A use-after-free on a path driven by local unprivileged sendmsg() is a local privilege escalation candidate, and a KASAN-less production kernel will more often just panic the node.

Who can reach it

Local, unprivileged: any process that can create AF_UNIX stream sockets on a host where a sockmap/sk_psock verdict program is attached. The attacker needs no capability of their own - the sockmap attachment is supplied by the platform's own CNI or mesh.

What to do

Update the host kernel to a build carrying the stable fix commits below (fetching sk->sk_socket and its ops under RCU) and reboot each node. As an interim measure, detaching the sockmap verdict program removes the vulnerable path, but on a mesh or CNI datapath that is a connectivity change, not a free mitigation.

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.