CVE-2026-46214

What it actually does

This is a Linux kernel availability flaw in the virtio vsock listener connection path. When a listening vsock socket receives a connection attempt that fails transport assignment or resolves to a different transport, the kernel increments the listener accept-queue backlog counter but does not decrement it on the error path. Repeating this condition eventually makes the listener appear permanently full, so legitimate new vsock connections are rejected until the listener or affected system state is reset.

Why it matters to the business

Successful exploitation can disrupt services that rely on virtio vsock for guest-to-host, host-to-guest, or VM-to-service communication, including management agents, telemetry, control-plane integrations, and local virtualization workflows. The issue requires local low-privileged access and currently has low EPSS, no known CISA KEV listing, and no reported mature public exploit, so broad internet-scale exploitation is unlikely; however, affected multi-user or workload-hosting systems should still prioritize remediation because the operational impact is service denial.

How an attack unfolds

An attacker first obtains local, low-privileged code execution on a system where Linux virtio vsock is available and where a target service is listening on a vsock socket. The attacker then repeatedly triggers connection attempts that reach the virtio vsock listen path but fail transport assignment or cause a transport mismatch. Each failed attempt incorrectly increments the listener backlog accounting without removing the failed entry. After roughly one more attempt than the configured listen backlog, the kernel believes the accept queue is full. From that point, legitimate clients attempting to connect to the affected vsock listener are rejected, causing a denial of service for functionality dependent on that listener. Recovery generally requires restarting the affected listener or otherwise clearing the kernel socket state, and durable remediation requires a patched kernel.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix moving sk_acceptq_added() until after successful transport validation in virtio_transport_recv_listen(). Because no exact fixed package versions were provided, use the relevant Linux distribution or appliance vendor advisory to identify the first patched kernel package for each supported release stream, including backported fixes where the upstream version number may not obviously change. If immediate patching is not possible, reduce exposure by disabling virtio vsock support where it is not required, unloading or blacklisting related modules only after confirming operational impact, restricting local shell/container access to trusted users, limiting untrusted workloads on affected hosts, and monitoring or restarting critical vsock-dependent services if they begin rejecting connections.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version for the applicable distribution release, not merely that a patched package is installed but not booted. Where source validation is possible, confirm the virtio vsock receive-listen path only calls sk_acceptq_added() after vsock_assign_transport() succeeds and the selected transport is validated. Confirm exposure by checking whether the kernel has vsock and virtio-vsock support enabled or modules loaded and whether local services are listening on AF_VSOCK sockets. Operationally validate by exercising normal vsock client connections after patching and confirming listeners do not become permanently unavailable after failed connection attempts.

Typical attack path

1. Gain local low-privileged access to a Linux system with virtio vsock support enabled.
2. Identify or infer a vsock listener used by a local VM, guest, host service, agent, or control-plane component.
3. Generate repeated malformed or transport-mismatched vsock connection attempts that enter the virtio listen path.
4. Cause the listener accept-queue backlog counter to leak upward on each failed attempt.
5. Exhaust the apparent backlog so the kernel treats the listener as full.
6. Prevent legitimate vsock clients from establishing new connections until the listener or system state is reset.

How to detect it

There are no reliable universal indicators that prove exploitation because the bug is an internal kernel accounting error and may not emit a distinctive log entry. To investigate possible prior exploitation, review systemd journal, kernel logs, hypervisor/guest logs, and affected application logs for time-correlated vsock listener outages, sudden connection refusals, or management-agent communication failures without a normal service crash. Use auditd, EDR, shell history, process accounting, or eBPF/network telemetry to look for untrusted local processes repeatedly creating AF_VSOCK sockets or generating bursts of failed vsock connection attempts shortly before service disruption. Also review restarts of vsock-dependent agents or services that temporarily restored connectivity, as this may indicate the listener state was exhausted rather than the service binary failing normally.

What your security team should do

• Prioritize patching Linux systems that run virtualization, guest agents, sandboxed workloads, CI runners, desktop virtualization, or host/guest management components using virtio vsock.
• Use vendor kernel advisories to map the upstream fix to exact package versions for each distribution and ensure systems are rebooted into the patched kernel.
• Inventory systems with AF_VSOCK and virtio vsock enabled, especially multi-user hosts and platforms running untrusted workloads.
• If patching is delayed, restrict local user and workload access, and disable virtio vsock only where business functionality does not depend on it.
• Add monitoring for sudden failures of vsock-dependent services, repeated local vsock connection failures, and restarts of management or guest-agent components.
• Because there is no KEV listing, no ransomware linkage, and very low EPSS, handle as a targeted/local availability risk rather than an internet-exposed emergency, unless affected systems host untrusted local workloads.