CVE-2024-53119

What it actually does

Race condition in virtio/vsock allows vsock_enqueue_accept to insert child sockets into accept_queue after flush but before SOCK_DONE is set during delayed close, leaving unreferenced socket allocations that are never freed.

Why it matters to the business

Virtualized environments using virtio vsock experience gradual kernel memory exhaustion that can degrade performance or trigger out-of-memory conditions; affected deployments include Ubuntu socat packages and upstream Linux kernels with no ransomware usage reported.

How an attack unfolds

An attacker triggers concurrent vsock listen/close paths (for example via crafted loopback or guest-host communication) to hit the window between accept_queue flush and SOCK_DONE; repeated successful races accumulate leaked sk_alloc objects without requiring remote code execution.

How to fix it

Apply the upstream fix in commit e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c or later; for Ubuntu 14.04 LTS upgrade socat to 1.7.2.3-1 or newer; for Ubuntu 16.04 LTS upgrade socat to 1.7.3.1-1 or newer.

How to confirm the fix worked

Confirm kernel contains the sk_shutdown guard before vsock_enqueue_accept; run vsock loopback stress tests while monitoring slabinfo or kmemleak for lingering vsock sockets; verify package versions match the listed fixed releases.

Typical attack path

1. Establish listening virtio vsock socket
2. Initiate close sequence that schedules delayed close_work and flushes accept_queue
3. Concurrently deliver recv_pkt that passes SOCK_DONE check and calls vsock_enqueue_accept
4. Allow close_work to set SOCK_DONE after enqueue, orphaning the child socket
5. Repeat to accumulate unreferenced allocations

How to detect it

Search kernel logs and kmemleak reports for repeated sk_prot_alloc backtraces originating from virtio_transport_recv_pkt or vsock_loopback_work; correlate with rising slab usage for vsock-related objects on systems that have not yet applied the shutdown check.

• unreferenced object.*size 2040.*comm "kworker
• backtrace.*virtio_transport_recv_pkt.*vsock_loopback_work
• kmem_cache_alloc_noprof.*sk_prot_alloc.*sk_alloc.*__vsock_create

What your security team should do

• Prioritize patching production kernels and socat packages within standard change windows
• Monitor memory usage trends on systems with heavy virtio vsock traffic
• Add the fix to internal kernel build pipelines and rebuild images
• Review virtio vsock usage in container or VM orchestration layers for exposure