CVE-2024-53118

What it actually does

The vulnerability causes a memory leak of skb objects queued on the vsock socket error queue for MSG_ZEROCOPY completions; these objects are never freed when the socket is destroyed.

Why it matters to the business

Systems relying on vsock sockets can experience gradual memory exhaustion, leading to degraded performance, increased swapping, or eventual denial of service.

How an attack unfolds

An attacker repeatedly creates vsock sockets, sends messages using MSG_ZEROCOPY, then destroys the sockets without draining the error queue, causing the kernel to leak allocated skb structures until memory is exhausted.

How to fix it

Upgrade the Linux kernel to a version containing commit bea4779a45f49275b1e1b1bd9de03cd3727244d8 or later stable releases that include the vsock error-queue cleanup fix.

How to confirm the fix worked

Run kmemleak after exercising vsock zerocopy paths and confirm no unreferenced skb objects remain; verify the fixed commit is present in the running kernel.

Typical attack path

1. Create a vsock socket
2. Perform a sendmsg operation with MSG_ZEROCOPY flag
3. Close or release the socket without calling recv on the error queue
4. Repeat the cycle to accumulate leaked allocations

How to detect it

Enable kernel memory leak detectors such as kmemleak and inspect for unreferenced skb allocations originating from virtio_transport_send_pkt_info; review process activity involving vsock sockets.

What your security team should do

• Apply the kernel patch containing the vsock error-queue fix as soon as possible
• Restrict untrusted code from creating vsock sockets until patches are deployed
• Monitor memory usage trends on systems that use vsock heavily