CVE-2026-46214: Linux Kernel vsock/virtio DoS Vulnerability

CVE-2026-46214 Overview

CVE-2026-46214 is a resource management flaw in the Linux kernel's vsock/virtio subsystem. The function virtio_transport_recv_listen() invokes sk_acceptq_added() before calling vsock_assign_transport(). When transport assignment fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listening socket to reject all subsequent connections. The flaw enables a denial-of-service condition against vsock listeners on affected Linux kernel builds.

Critical Impact

Repeated transport-mismatch connection attempts permanently inflate the accept queue counter, eventually blocking all new vsock connections to the listener.

Affected Products

• Linux kernel branches containing the vsock/virtio transport implementation prior to the referenced stable commits
• Virtualization hosts and guests relying on virtio-vsock for hypervisor-guest communication
• Container and confidential computing platforms using vsock listeners

Discovery Timeline

• 2026-05-28 - CVE-2026-46214 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46214

Vulnerability Analysis

The vulnerability resides in virtio_transport_recv_listen() within the Linux kernel's virtio vsock transport layer. The function accounts for an incoming connection on the listener's accept queue by calling sk_acceptq_added() prior to validating that a transport can actually service the connection.

If vsock_assign_transport() subsequently fails or returns a transport different from the one expected, the error-handling path exits without a paired sk_acceptq_removed() call. The counter sk_ack_backlog increases on every failed attempt without ever being decremented.

Once the leaked count exceeds the socket's configured backlog, sk_acceptq_is_full() returns true on every check. The listener then rejects all valid connection attempts, producing a persistent denial of service that survives until the listening socket is closed and recreated.

Root Cause

The root cause is incorrect ordering of accounting and validation operations. Accept-queue accounting executes before transport validation, breaking the acquire-release symmetry that the kernel's socket API expects. The fix moves sk_acceptq_added() to after successful transport validation, aligning the code with the patterns already implemented in vmci_transport and hyperv_transport.

Attack Vector

An attacker with the ability to initiate vsock connections to a listening socket can repeatedly trigger transport mismatches. Each failed attempt leaks one accept-queue slot. After enough iterations, the listener becomes unreachable. The attack does not require kernel privileges, only the ability to open vsock sockets from a guest, container, or local context that can reach the listener.

No verified public exploitation code is associated with this CVE. The fix is distributed across the Linux kernel stable commits 29371f3, 52bcb57, 65c4847, 6d3275f, and e9edf98.

Detection Methods for CVE-2026-46214

Indicators of Compromise

• Vsock listener sockets that stop accepting connections while remaining in the LISTEN state.
• Elevated sk_ack_backlog values reported by socket diagnostics without a corresponding number of accepted connections.
• Repeated ECONNRESET or connection-refused errors from clients targeting AF_VSOCK services.

Detection Strategies

• Compare running kernel versions against the patched stable branches referenced in the kernel.org commits.
• Audit virtualization hosts and guests for use of virtio-vsock listeners and inventory services that bind on AF_VSOCK.
• Inspect kernel logs for high volumes of vsock connection attempts originating from a single guest or container.

Monitoring Recommendations

• Track ss -lx and /proc/net/vsock output for vsock listeners whose accept queue depth grows without matching accept activity.
• Alert on processes that issue large bursts of connect() calls against AF_VSOCK sockets.
• Forward kernel and audit logs to a centralized analytics platform to correlate failed vsock connections across the fleet.

How to Mitigate CVE-2026-46214

Immediate Actions Required

• Apply the latest Linux kernel update from your distribution that incorporates the upstream stable patches.
• Restart vsock listener services after patching to clear any leaked accept-queue counters from prior exploitation attempts.
• Restrict which guests, containers, or local users can initiate vsock connections to sensitive listeners.

Patch Information

The upstream fix reorders sk_acceptq_added() to execute only after vsock_assign_transport() validates the transport, mirroring the behavior of vmci_transport and hyperv_transport. The patch is available in the kernel.org stable tree under commits 29371f3, 52bcb57, 65c4847, 6d3275f, and e9edf98. Distribution vendors should ship corresponding kernel updates; consult vendor advisories for backports.

Workarounds

• Periodically restart processes that hold long-lived AF_VSOCK listeners to reset sk_ack_backlog until patches are applied.
• Where feasible, disable or unload the vmw_vsock_virtio_transport module on hosts that do not require virtio vsock connectivity.
• Use hypervisor-level controls to limit which guests can communicate with vsock listeners on the host.

# Verify the running kernel and reload vsock modules after patching
uname -r
lsmod | grep vsock
modprobe -r vmw_vsock_virtio_transport 2>/dev/null || true