CVE-2026-53181

What it actually does

This is a denial-of-service flaw in the Linux kernel VMCI vsock transport. When a server-side vsock connection handshake fails on a specific error path, the kernel removes the pending connection but does not decrement the listener socket's accept-backlog counter. Repeated failed handshakes can permanently inflate sk_ack_backlog until it reaches sk_max_ack_backlog, after which the listener refuses new connections even though the accept queue is not actually full. Recovery typically requires restarting the affected listening process or otherwise recreating the socket.

Why it matters to the business

Systems that rely on VMCI/vsock communication, commonly for host-to-guest, guest-to-host, or VM service communication, can experience silent service interruption. Applications may appear healthy but stop accepting new vsock connections, causing automation, agents, management channels, or inter-VM services to fail until restarted. Current public exploitation signals are low: EPSS is 0.00123, it is not listed in CISA KEV, it is not marked as ransomware-used, and no exploit maturity is reported; however, exposed or multi-tenant virtualization workloads should still prioritize patching because exploitation can be repeated and may not leave clear forensic artifacts.

How an attack unfolds

An attacker able to initiate VMCI/vsock connection attempts to a vulnerable listener repeatedly triggers handshake failures, such as by sending malformed connection attempts or causing setup failures in the VMCI transport path. Each failed attempt causes the kernel to remove the pending socket but leaves the listener backlog count incremented. Over time, the listener's perceived backlog reaches its configured maximum. Once this happens, legitimate clients attempting to connect receive connection refusals, and the service remains unavailable for new connections until the listener socket is recreated, commonly by restarting the affected process.

How to fix it

Apply a Linux kernel update that includes the upstream fix balancing sk_acceptq_added() with sk_acceptq_removed() on the VMCI/vsock failed-handshake path. No exact product package or fixed version was provided, so use the relevant Linux distribution or appliance vendor advisory and update to the first kernel build that references this fix or a later supported kernel. If immediate patching is not possible, reduce exposure by disabling unused vsock/VMCI functionality, unloading or preventing use of vmw_vsock_vmci_transport where operationally safe, limiting which VMs or local principals can reach vsock services, and restarting affected listener processes if they begin refusing connections. Because the defect is in kernel accounting, application-level retries alone do not remediate the issue.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the installed vendor kernel changelog or source package for the VMCI/vsock backlog accounting correction in vmci_transport_recv_listen()/vmci_transport_recv_connecting_server() error handling. Verify whether the system is exposed by checking for loaded vsock/VMCI modules and active AF_VSOCK listeners. After patching, reboot or otherwise ensure the fixed kernel is running, then validate that affected services can accept new vsock connections after failed connection attempts. Operational validation should include confirming that connection refusals no longer persist until process restart after handshake failures.

Typical attack path

1. Identify a service or agent listening on AF_VSOCK/VMCI on a vulnerable Linux kernel.
2. Establish the ability to send repeated VMCI/vsock connection attempts from an adjacent guest, host, or permitted VM communication context.
3. Send connection attempts that fail during the VMCI handshake path, such as malformed or otherwise invalid handshakes.
4. Repeat the failed handshakes until the kernel listener backlog counter reaches its maximum.
5. Legitimate clients begin receiving connection refusals even though the listener is still running.
6. Service availability is restored only after the listening socket is recreated, usually through process restart or kernel update plus restart/reboot.

How to detect it

There may be no definitive on-host artifact proving exploitation because the flaw corrupts kernel socket backlog accounting rather than creating files or running attacker commands. Review kernel logs, system logs, application logs, and virtualization platform logs for repeated failed AF_VSOCK/VMCI connection attempts followed by persistent connection refusals for a vsock-based service. Look for service health checks that remain green while clients receive ECONNREFUSED, unexplained restarts of agents using vsock, and bursts of failed connections from the same VM, guest context, or host context. If deeper telemetry is available, use eBPF, ftrace, kprobes, or kernel tracing to monitor error returns from VMCI/vsock handshake functions and compare accept-backlog behavior against successful accepts. Correlate suspected activity with loaded vmw_vsock_vmci_transport/vsock modules and active AF_VSOCK listeners.

• ECONNREFUSED
• Connection refused
• AF_VSOCK
• VMCI
• vsock
• vmw_vsock_vmci_transport
• vmci_transport_recv_connecting_server
• vmci_transport_recv_listen
• sk_ack_backlog
• sk_max_ack_backlog

What your security team should do

• Inventory Linux systems using AF_VSOCK, VMCI, VMware guest/host communication, or services dependent on vsock transport.
• Prioritize kernel updates on virtualization hosts, guests, appliances, and management-plane components where untrusted or semi-trusted workloads can initiate vsock connections.
• If patching is delayed, disable unused VMCI/vsock transports or restrict access to vsock services where feasible.
• Monitor for bursts of failed vsock connection attempts and sudden persistent ECONNREFUSED errors from services that use AF_VSOCK.
• Create operational runbooks to restart affected listener processes as a temporary recovery measure, but treat restart as mitigation only, not remediation.
• Because the issue is not in CISA KEV and has low EPSS, schedule broadly according to normal kernel patch cycles, but accelerate for shared virtualization and multi-tenant environments.