CVE-2026-53132: vsock/virtio: fix potential unbounded skb queue
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: fix potential unbounded skb queue
virtiotransportincrxpkt() checks vvs->rxbytes + len > vvs->bufalloc.
virtiotransportrecvenqueue() skips coalescing for packets with VIRTIOVSOCKSEQEOM.
If fed with packets with len == 0 and VIRTIOVSOCKSEQEOM, a very large number of packets can be queued because vvs->rxbytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) SKBTRUESIZE(0)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix that estimates skb metadata size and prevents vvs->rx_bytes staying at 0 from allowing an unbounded skb queue for packets where len == 0 and VIRTIO_VSOCK_SEQ_EOM.
Linux kernel (vsock/virtio transport) skb metadata size estimation (fix for unbounded skb queue when len == 0 and VIRTIO_VSOCK_SEQ_EOM) = enabled
Event History
Frequently Asked Questions
What conditions are required to trigger the resource exhaustion?
An attacker must be able to feed the virtio-vsock receive path a large number of zero-length packets carrying the VIRTIO_VSOCK_SEQ_EOM flag. These packets bypass coalescing, while their zero payload length prevents rx_bytes from increasing.
What is the practical impact?
The receive queue can accumulate a very large number of socket buffers without reaching the normal byte-based buffer allocation limit. This can exhaust memory or otherwise cause a denial of service.
How does the fix prevent the issue?
The fix accounts for socket-buffer metadata in addition to payload bytes. It estimates queued overhead using the number of queued skbs multiplied by SKB_TRUESIZE(0), preventing zero-length packets from being treated as consuming no receive-buffer capacity.