CVE-2026-23086 in Linux
Summary
by MITRE • 02/04/2026
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: cap TX credit to local buffer size
The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.
On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.
Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc.
This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.
On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.
With this patch applied:
Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB
After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB
Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.
Compatibility with non-virtio transports:
- VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured.
- Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes.
- The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.
This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.
[Stefano: small adjustments after changing the previous patch]
[Stefano: tweak the commit message]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/03/2026
The vulnerability described in CVE-2026-23086 affects the Linux kernel's virtual socket implementation, specifically within the virtio transport layer that facilitates communication between virtual machines and their hosts. This issue stems from an improper handling of transmit credit allocation that allows remote endpoints to influence local memory allocation behavior. The flaw occurs when the virtio transport system directly uses the peer's buffer allocation value, which is communicated through the SO_VM_SOCKETS_BUFFER_SIZE socket option, to determine how much data can be queued locally. This creates a potential denial-of-service scenario where a malicious guest operating system can advertise arbitrarily large buffer sizes while reading data slowly, leading to excessive memory consumption on the host system.
The technical root cause of this vulnerability lies in the lack of bounds checking on transmit credit values received from remote endpoints. The system derives transmit credits directly from peer_buf_alloc, which is set based on the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value, without considering the host's own buffer allocation limits. This design flaw enables a malicious guest to cause the host to allocate excessive sk_buff memory, effectively creating a memory exhaustion condition that can lead to system instability or complete system hangs. The vulnerability affects all virtio-based vsock implementations, including virtio-vsock, vhost-vsock, and the loopback path, since they all share the same underlying code base.
The operational impact of this vulnerability is significant, particularly in virtualized environments where multiple guests may be running simultaneously. As demonstrated in the proof-of-concept scenario, a single malicious guest can cause the host system's Slab/SUnreclaim memory usage to increase dramatically from approximately 0.5 GiB to over 57 GiB, consuming nearly the entire system memory. This memory exhaustion can result in system-wide performance degradation, application crashes, or even complete system lockups that require manual intervention such as killing the QEMU process. The vulnerability is particularly dangerous in containerized or cloud environments where resource constraints are critical, and where memory limits imposed by cgroups may not be sufficient to prevent the memory exhaustion caused by this attack vector.
The patch implemented to address this vulnerability introduces a helper function called virtio_transport_tx_buf_size() that returns the minimum of peer_buf_alloc and buf_alloc values, effectively bounding the transmit window by both the peer's advertised buffer size and the host's own buffer allocation limits. This approach ensures that the effective transmit window is constrained by the local vsock configuration parameters, which are already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE. The mitigation strategy directly addresses the core issue by implementing a "remote window intersected with local policy" behavior that aligns with how other vsock transports such as VMCI and Hyper-V already operate. This change prevents remote peers from forcing local systems to queue more data than their own configuration allows, thereby protecting against memory exhaustion attacks.
The fix maintains compatibility with non-virtio transports by preserving their existing behavior patterns. VMCI transport already uses local buffer configuration values to size its queue pairs, preventing remote endpoints from enlarging local queues beyond local configuration limits. Hyper-V's vsock transport uses fixed-size VMBus ring buffers with MTU bounds, eliminating the possibility of peer-controlled credit fields that could be exploited. The loopback path naturally inherits the same semantics as the virtio transport due to code reuse. This patch affects only the virtio_transport_common.c file, ensuring that virtio-vsock, vhost-vsock, and loopback implementations all follow consistent behavior patterns. The memory usage statistics demonstrate the effectiveness of the fix, showing only a minimal increase in Slab/SUnreclaim memory usage from approximately 117 MiB to 152 MiB after applying the patch, compared to the dramatic increase observed in the vulnerable state. This aligns with CWE-400 vulnerability classification related to excessive resource consumption and demonstrates effective adherence to the principle of least privilege in resource allocation.
The solution represents a robust approach to preventing resource exhaustion attacks in virtualized networking environments, following established security patterns where remote inputs are always bounded by local policy constraints. The implementation ensures that even in the presence of malicious remote endpoints, local system resources remain protected through proper input validation and resource limitation mechanisms. This vulnerability highlights the importance of careful resource management in virtualized environments where trust boundaries between host and guest systems are not absolute, and demonstrates how seemingly minor design flaws in network transport implementations can lead to significant security and stability issues. The fix exemplifies proper security engineering practices by ensuring that remote inputs are never allowed to directly control local resource allocation decisions without appropriate bounds checking and validation.