GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sockmap: vsock or AF_UNIX socket in a sockmap faults in tls_sw_ctx_rx

CVSS 5.5CVE-2024-53091Kernel, userspace & hypervisorcurated

Impact

After sockmap gained vsock and AF_UNIX support, tls_sw_has_ctx_tx/rx still assumed every socket handed to it was an inet_connection_sock. For a vsock_sock or unix_sock, tls_get_ctx() returns a bogus pointer and the kernel takes an unhandled page fault in sk_psock_strp_data_ready(), as in the reported vsock-loopback trace. This matters where sockmap is actually in production - Cilium-style service mesh and socket-level load balancing on the fleet - because the fault lands in softirq/workqueue context and takes the node down with every GPU job on it. Availability only; no data disclosure is described.

Who can reach it

Local: a process able to add a vsock or AF_UNIX socket to a sockmap, which means a privileged agent or a workload granted BPF map access, on a kernel with sockmap+kTLS in use. Not reachable without sockmap configured.

What to do

Update to a stable kernel with the sk_is_inet()/IS_ICSK check (linked commits) and reboot the node. As an interim measure, do not place vsock or AF_UNIX sockets into sockmaps. No vendor fixed-version string is present in the record - the fix landed around 6.12 stable plus backports.

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.