CVE-2024-53117

What it actually does

Missing kfree_skb() call in error path of virtio/vsock MSG_ZEROCOPY handling allows skb buffers to leak without being freed.

Why it matters to the business

Prolonged operation under error conditions can lead to gradual memory exhaustion, degrading performance or causing instability on systems using virtio vsock, with low immediate risk given stable low exploit probability and no known campaigns.

How an attack unfolds

An attacker triggers repeated error conditions in the MSG_ZEROCOPY path of virtio vsock, such as through specific packet sequences or resource contention, causing skb allocations that are never released, eventually exhausting kernel memory.

How to fix it

Update the Linux kernel to the fixed commit 50061d7319e21165d04e3024354c1b43b6137821 or later stable releases; apply equivalent updates for affected distributions such as libtasn1-6 packages on Ubuntu 14.04 and 16.04 where backported fixes are available.

How to confirm the fix worked

Verify kernel version or git commit includes the kfree_skb addition in virtio/vsock; inspect source for the error handling path and confirm no unreleased skbs under test error scenarios.

Typical attack path

1. Identify target using virtio/vsock communication
2. Craft inputs that force error return in MSG_ZEROCOPY handling
3. Repeat to accumulate leaked skb memory
4. Monitor for system memory pressure or crashes

How to detect it

Review kernel logs for repeated vsock error paths coinciding with unexplained memory growth; examine skb allocation patterns in virtio/vsock code paths for signs of accumulation without corresponding frees.

What your security team should do

• Prioritize kernel updates on systems with heavy virtio/vsock usage within standard patch cycles
• Monitor memory usage metrics for vsock-enabled workloads
• Review virtio/vsock configurations for unnecessary exposure