CVE-2026-46214: Linux vsock Accept Queue Leak Causes Listener Denial of Service

Technical summary

The vulnerability exists in virtio_transport_recv_listen() within the vsock/virtio subsystem. The function calls sk_acceptq_added() to increment the accept queue backlog counter before validating and assigning the appropriate transport via vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling the corresponding sk_acceptq_removed(), leaving the backlog counter in an inconsistent state. After approximately backlog+1 such failures, sk_acceptq_is_full() incorrectly returns true, causing the listener socket to reject all new connections. The fix relocates sk_acceptq_added() to execute after successful transport validation, aligning the implementation with existing patterns in vmci_transport and hyperv_transport.

Business impact

Applications using vsock for inter-process or inter-VM communication on Linux systems may experience unexpected connection rejections after repeated transport negotiation issues. This denial-of-service condition could disrupt container-to-host communication, virtual machine management operations, or other vsock-dependent services. The impact manifests gradually—after a threshold of failed connections is reached, the listener becomes unresponsive to all new connection attempts until the process is restarted, forcing service interruption or recovery procedures.

Affected systems

The vulnerability affects the Linux kernel vsock/virtio transport implementation. Any Linux system running a vulnerable kernel version and hosting applications that use vsock for network-like communication is potentially affected. This includes container runtimes, hypervisor management layers, and any user-space application communicating via /dev/vsock sockets. The vulnerability is platform-independent within Linux but only manifests when vsock is actively in use and transport selection failures occur.

Exploitability

The vulnerability requires local access to trigger—specifically, the ability to initiate vsock connections on the affected system. An unprivileged local user can attempt connections with invalid or mismatched transport configurations to incrementally exhaust the accept queue. No special kernel privileges, network access, or exploit code is required; repeated connection attempts with transport mismatches will gradually degrade the listener's availability. The barrier to exploitation is low due to the local-only requirement and the passive nature of the bug (no active exploitation mechanism needed beyond normal vsock usage).

Remediation

Patch the Linux kernel to a version containing the fix. The remediation involves moving the sk_acceptq_added() call to execute only after vsock_assign_transport() has successfully validated and selected a transport, ensuring the backlog counter remains consistent. Affected administrators should check their kernel's patch status and apply security updates from their Linux distribution. Kernel module rebuilds or backported patches may be necessary for older supported kernels if the distribution has not yet released a patched version.

Patch guidance

Apply the latest kernel security update from your Linux distribution that includes this vsock/virtio fix. Verify against the vendor advisory that the specific patch addressing the accept queue count leak in vsock/virtio is included. Reboot the system after applying kernel updates to activate the patched code. If running a custom or long-term support kernel, check the kernel security tracking resources or your vendor's advisory to confirm the fix has been applied to your kernel version.

Detection guidance

Monitor for increased connection rejections on vsock listeners, particularly after transport-related errors in kernel logs. Systems experiencing the issue will show accept queue backlog counter growing persistently without corresponding decrements. Observe kernel logs for vsock transport assignment failures or mismatches coinciding with application-level connection refusals. Restart the listening application and observe whether connections are briefly accepted again before the counter leaks resume—this pattern is diagnostic of the vulnerability.

Why prioritize this

Although the CVSS score is medium (5.5) and local access is required, the vulnerability can cause a complete denial of service for critical inter-process and inter-VM communication channels. Container orchestration, hypervisor management, and secure enclave communication may all rely on vsock. The gradual nature of the degradation (connections work until a threshold is reached) makes it particularly insidious for production environments where sporadic failures may be initially misdiagnosed as application bugs rather than a kernel issue. Prioritize patching for systems where vsock is actively used for mission-critical communication.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects a local-only attack vector with low complexity and low privilege requirements, resulting in high availability impact but no confidentiality or integrity consequences. The score accurately captures the denial-of-service nature of the flaw. However, context matters: environments where vsock carries critical workload communication should treat this as higher priority than the base score suggests, while systems not using vsock can deprioritize it.

Frequently asked questions