CVE-2026-46214
Received Received - Intake
Memory Leak in Linux Kernel vsock/virtio Transport

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() 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 listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by updating the Linux kernel to a version where the accept queue count leak on transport mismatch in vsock/virtio is resolved.

Specifically, the fix involves moving the sk_acceptq_added() call to after transport validation to prevent the accept queue count from leaking and causing the listener to reject new connections.

Therefore, the immediate mitigation step is to apply the kernel update that includes this fix.


Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's vsock/virtio subsystem. The issue arises because the function virtio_transport_recv_listen() calls sk_acceptq_added() before validating the transport with vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), which causes the accept queue count (sk_ack_backlog) to be permanently incremented.

As a result, after approximately backlog+1 such failures, the accept queue becomes full (sk_acceptq_is_full() returns true), causing the listener to reject all new incoming connections. The fix involved moving the call to sk_acceptq_added() to after the transport validation to ensure the accept queue count is correctly managed.


How can this vulnerability impact me? :

This vulnerability can lead to a denial of service condition where the listener in the vsock/virtio subsystem rejects all new incoming connections after a certain number of transport mismatches or failures. This happens because the accept queue count is leaked and eventually fills up, preventing new connections from being accepted.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart