CVE-2026-23086: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-23086 is a memory exhaustion (denial-of-service) vulnerability in the Linux kernel's virtio vsock transport layer, specifically in the TX credit mechanism. The flaw allows a malicious guest or host to advertise an excessively large socket buffer size, causing the victim endpoint to queue an uncontrolled amount of kernel memory in sk_buff structures. It affects Linux kernel versions from 4.8 up to (but not including) 6.1.162, 6.2–6.6.x before 6.6.122, 6.7–6.12.x before 6.12.68, and 6.13–6.18.x before 6.18.8, as well as 6.19-rc1 through rc6. First published on February 4, 2026, with patches released March 17, 2026, it carries a CVSS v3.1 base score of 5.5 (Medium) (Feedly).

The root cause is improper resource control (CWE-400: Uncontrolled Resource Consumption) in the virtio vsock transport's TX credit accounting. The TX credit window is derived directly from peer_buf_alloc, a value set by the remote endpoint via SO_VM_SOCKETS_BUFFER_SIZE, without being bounded by the local endpoint's own buf_alloc configuration. A malicious peer can advertise a very large buffer (e.g., 2 GiB) and then read data slowly, forcing the victim to continuously queue sk_buff memory up to the peer-advertised limit. The vulnerability affects virtio-vsock, vhost-vsock, and loopback transports, since they share the same code base. The fix introduces a virtio_transport_tx_buf_size() helper that returns min(peer_buf_alloc, buf_alloc), ensuring the effective TX window is bounded by both the peer's advertised buffer and the local configuration (Feedly, Kernel Patch).

Successful exploitation results in severe availability impact with no effect on confidentiality or integrity. A malicious guest using 32 vsock connections each advertising 2 GiB of buffer caused Slab/SUnreclaim memory to grow from approximately 0.5 GiB to ~57 GiB on a 64 GiB Ubuntu 22.04 host, rendering the system unresponsive and requiring the QEMU process to be killed to recover. The attack is bidirectional — a malicious host can equally exhaust guest kernel memory — and affects any virtualization environment using virtio-vsock, vhost-vsock, or loopback vsock transports (Feedly).

1. Setup: Obtain access to a guest VM (or host) running an unpatched Linux kernel (e.g., 4.8–6.18.7) with virtio-vsock support enabled.
2. Open multiple vsock connections: From the malicious guest, establish a large number of vsock connections to the host (e.g., 32 connections) using the vsock API targeting the host's CID.
3. Advertise large buffer: For each connection, set SO_VM_SOCKETS_BUFFER_SIZE to a very large value (e.g., 2 GiB) before or after connecting, causing the guest to advertise peer_buf_alloc = 2 GiB to the host.
4. Send data without reading: Continuously write data into each vsock connection from the guest side without reading from the guest's receive buffer, causing the host to queue sk_buff memory up to the peer-advertised 2 GiB limit per connection.
5. Exhaust host memory: With 32 connections × 2 GiB each, the host's kernel Slab/SUnreclaim memory grows rapidly (demonstrated: ~0.5 GiB to ~57 GiB), causing the host to become unresponsive or OOM-kill critical processes (Feedly).

• Kernel Memory: Rapid and sustained growth of Slab and SUnreclaim memory visible in /proc/meminfo; values climbing to tens of GiB without corresponding application-level memory usage.
• Process: High number of vsock connections from a single guest CID observable via ss -x or ss --vsock; QEMU process consuming abnormally large amounts of kernel memory.
• Logs: Kernel OOM killer messages in /var/log/kern.log or dmesg related to kvm/qemu processes; kernel warnings about excessive socket buffer allocation.
• Network: Unusually high number of active vsock connections (e.g., 30+) from a single guest, visible via ss -a --vsock on the host; connections remaining open with large send queues and minimal receive activity.

Apply the patched Linux kernel versions: 6.1.162 or later (for 4.8–6.1.x), 6.6.122 or later (for 6.2–6.6.x), 6.12.68 or later (for 6.7–6.12.x), or 6.18.8 or later (for 6.13–6.18.x). Patches are available from the kernel stable branches at git.kernel.org. As a partial workaround prior to patching, configure cgroup memory limits on QEMU/virtualization workloads to cap maximum memory allocation, and set conservative SO_VM_SOCKETS_BUFFER_MAX_SIZE values to limit the maximum TX window size — note these do not fully remediate the vulnerability (Feedly, Kernel Patch).

Vendor advisories have been issued by SUSE (SUSE-2026-0962-1), Oracle Linux (ELISA-2026-50160, ELSA-2026-50232), and Ubuntu (USN-8393-1), indicating broad distribution-level response to the vulnerability. Google Cloud release notes also reference the fix. Coverage has appeared on Linux security news aggregators and German Linux community sites, reflecting standard industry response to a kernel DoS vulnerability without significant broader media attention (Feedly).