Cloudanix VulnDB

CVE-2026-99122

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A missing check in the Linux kernel's virtual socket code lets one virtual machine send a reset packet that can unexpectedly close a connection belonging to another virtual machine.

Exploitation
Adjacent Network
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vmci_transport_recv_stream_cb function performs a destination-only lookup in the bound socket table as a fallback and accepts packets without verifying the source against the socket's stored peer, allowing an attacker-controlled VMCI context to deliver RST or other control packets to connected sockets.

Why it matters to the business

Attackers with access to a second VMCI context can disrupt established vsock connections, causing application-level communication failures between virtual machines or containers that rely on this transport.

How an attack unfolds

An attacker with a second VMCI context sends a crafted RST packet addressed to a destination that matches a socket in TCP_SYN_SENT state; the destination-only fallback lookup selects the socket, the missing source check allows the RST to be processed, and the socket is reset without ever reaching its intended peer.

How to fix it

Apply the upstream kernel patch that adds vsock_check_source validation after socket lock acquisition in both bottom-half and workqueue paths; rebuild and deploy the updated kernel on all affected systems. Until patched, restrict VMCI context creation to trusted entities where possible.

How to confirm the fix worked

Confirm the presence of the vsock_check_source call immediately after lock acquisition in vmci_transport_recv_stream_cb and verify that listening sockets still accept packets from any source while connected sockets enforce peer validation.

Typical attack path

  1. Obtain a second VMCI context on the same host or hypervisor
  2. Identify or trigger a socket in TCP_SYN_SENT or other connected state via destination address
  3. Send a VMCI notification or stream packet with a matching destination but spoofed or alternate source
  4. Trigger the fallback lookup path in bottom-half or workqueue context
  5. Observe socket reset or connection termination

How to detect it

Monitor kernel logs for unexpected RST generation on vsock sockets, unusual source validation failures, and any workqueue or bottom-half paths that terminate connections without user-space involvement; correlate with VMCI context creation events.

What your security team should do

  • Prioritize kernel updates for all systems using VMCI vsock within the next 7 days given the public fix and recent disclosure
  • Review hypervisor and VM configurations to limit unnecessary VMCI context sharing
  • Add kernel version checks to vulnerability scanning pipelines for this class of socket source validation issues

The record

In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: validate packet source for connected sockets vmci_transport_recv_stream_cb() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback can select a non-listening socket without checking whether the packet came from its stored peer. This was reproduced with two VMCI contexts. A RST from the context not stored in a TCP_SYN_SENT socket reset that socket after it was selected by the destination-only lookup. VMCI can process notification packets in bottom-half context when the socket is not owned by user context, or defer packets to a workqueue. Use vsock_check_source() after taking the socket lock in the bottom-half path, and recheck after lock_sock() in the workqueue path. Listening sockets continue to accept packets from any source. Reply with a RST addressed from the received packet before dropping a source that fails validation. This preserves the existing reset behavior for bound non-listening and concurrently closed sockets without directing the reset to a connected socket's stored peer.

Affected packages

Ecosystem Package Introduced Fixed