---
id: "CVE-2026-99123"
kind: "vulnerability"
aliases: ["CVE-2026-99123"]
title: "Linux kernel: virtio vsock accepts packets from unrelated sources"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["linux-kernel", "runtime", "virtio", "virtualization", "vsock"]
not_affected_if: ["no-untrusted-local-users", "no-virtio-vsock"]
published_at: "2026-10-28T11:17:31+00:00"
first_seen_at: "2026-10-28T11:32:34+00:00"
updated_at: "2026-10-28T11:37:30+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99123", "first_seen_at": "2026-10-28T11:32:34+00:00"}]
---

# Linux kernel: virtio vsock accepts packets from unrelated sources

A connected AF_VSOCK socket in the Linux kernel can be moved to an established state by a packet from an unrelated source, because the virtio receive path falls back to destination-only socket lookup without checking the source. A local unprivileged process can then inject data into the victim socket, which reads attacker-chosen bytes.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel version listed by your distribution's advisory for CVE-2026-99123
- `lsmod | grep -E 'vmw_vsock_virtio_transport|vhost_vsock'` to see whether virtio vsock is loaded at all
- unknown whether the sources list a specific affected version range

## Fix

- Update the Linux kernel to a release that includes the vsock_check_source() fix, per your distribution's kernel update
- If vsock is not needed, unload or blacklist `virtio_vsock` and `vhost_vsock` until patched (unknown whether this fully mitigates on every configuration)

## Timeline

- 2026-10-28T11:32:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99123

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: validate packet source for connected sockets

virtio_transport_recv_pkt() looks up sockets first by the full source and
destination tuple, then by destination only in the bound table. The
fallback is needed for listening and connecting sockets, but sockets remain
in the bound table after connect(), so it can also return a non-listening
socket.

The fallback does not validate the source address. In TCP_SYN_SENT, a
RESPONSE from an unrelated source can transition the victim socket to
TCP_ESTABLISHED while its stored remote address remains unchanged.
Subsequent RW packets from that source are delivered through the same
destination-only fallback.

This was reproduced with capability-empty processes under different UIDs.
The attacker discovered the target tuple through unprivileged AF_VSOCK
sock_diag and caused the victim socket to read 16 attacker-chosen bytes;
the intended peer-side socket read 0 of those 16 bytes.

Add vsock_check_source() to validate the transport, source port and source
CID against the peer stored in a non-listening socket. The local transport
is the CID exception because its packets are generated internally with
VMADDR_CID_LOCAL as their source, including connections using CID aliases.

Use the helper after lock_sock() in the virtio receive path.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_