CVE-2026-46207: Linux Kernel vsock/virtio Vulnerability

CVE-2026-46207 Overview

CVE-2026-46207 is an uninitialized memory use vulnerability in the Linux kernel's vsock/virtio subsystem. The flaw resides in virtio_transport_build_skb(), which calls virtio_transport_copy_nonlinear_skb() to copy payload data into a new socket buffer destined for the vsockmon tap device. The helper manually initializes an iov_iter structure but fails to set iov_iter.count, leaving it zero. As a result, no payload is copied to the monitor interface, and the tap skb is delivered with uninitialized kernel memory in place of the expected data.

Critical Impact

Tap socket buffers delivered to vsockmon monitor interfaces contain uninitialized kernel memory, potentially exposing sensitive data to processes capturing vsock traffic.

Affected Products

• Linux kernel — vsock/virtio transport (mainline)
• Linux stable kernel branches receiving the referenced backports
• Distributions packaging affected stable kernels prior to the fix commits

Discovery Timeline

• 2026-05-28 - CVE-2026-46207 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46207

Vulnerability Analysis

The Linux kernel's vsock/virtio transport supports duplication of socket buffers to a vsockmon tap device for traffic monitoring. When the original skb is non-linear, virtio_transport_build_skb() delegates payload copying to virtio_transport_copy_nonlinear_skb(). This helper builds an iov_iter on the stack to describe the destination buffer but neglects to populate the count field. Because the structure is zero-initialized, the copy operation walks zero bytes and returns without writing payload data. The resulting tap skb retains whatever kernel memory occupied the newly allocated buffer, which is then delivered to any process observing the vsockmon interface.

Root Cause

The root cause is improper initialization of an iov_iter structure prior to use in a kernel-to-kernel copy path. Manual construction of the iterator omitted the byte count, which controls how much data is transferred. With count set to zero, the copy is a no-op, and the destination skb is forwarded with uninitialized contents. This is an Uninitialized Memory Use defect [CWE-908] that surfaces as an information exposure to monitoring consumers.

Attack Vector

Exploitation requires the ability to observe traffic on the vsockmon tap interface, which typically requires elevated privileges such as CAP_NET_ADMIN. An adversary with that access can capture frames containing residual kernel memory from skb allocations. While this is not a remote code execution path, the leaked bytes may include sensitive kernel data adjacent to networking allocations. The upstream remediation removes the linear vs non-linear split entirely and replaces it with skb_copy_datagram_iter() combined with iov_iter_kvec(), mirroring the approach already used by vhost-vsock. The fix also adds error checking on the return value of skb_copy_datagram_iter().

Detection Methods for CVE-2026-46207

Indicators of Compromise

• Presence of vsockmon tap interfaces on systems running unpatched kernels with vsock/virtio enabled.
• Captured vsockmon frames whose payload bytes do not match the original vsock traffic sent or received by guests.
• Loaded vsock, vmw_vsock_virtio_transport, or vhost_vsock modules on kernels lacking the referenced commits.

Detection Strategies

• Compare installed kernel versions against the fix commits 06747f52ab15, 378b131a25bd, 3a3e3d90cbc7, and 52da6a74ca3d from the kernel.org stable tree.
• Audit hosts running virtualization workloads using virtio-vsock and verify whether vsockmon is in use for diagnostics.
• Use distribution security trackers to confirm vendor backports have been applied to deployed kernel packages.

Monitoring Recommendations

• Track creation of vsockmon interfaces via ip link auditing or netlink monitoring on production hypervisors.
• Log loading of vsock family modules and correlate with the kernel build identifier reported by uname -r.
• Review packet captures taken from vsockmon for anomalous content patterns that could indicate the uninitialized-memory condition.

How to Mitigate CVE-2026-46207

Immediate Actions Required

• Inventory all Linux hosts running virtio-vsock workloads, including KVM/QEMU hypervisors and Firecracker deployments.
• Apply vendor kernel updates that incorporate the upstream fix replacing virtio_transport_copy_nonlinear_skb() with skb_copy_datagram_iter().
• Restrict CAP_NET_ADMIN and access to vsockmon interfaces to trusted administrators only.

Patch Information

The vulnerability is resolved in the Linux stable tree through the following commits: 06747f52ab15, 378b131a25bd, 3a3e3d90cbc7, and 52da6a74ca3d. The fix removes the linear vs non-linear branch in virtio_transport_build_skb(), uses iov_iter_kvec() to correctly initialize the iterator, and checks the return value of skb_copy_datagram_iter().

Workarounds

• Avoid creating vsockmon tap interfaces on unpatched hosts until kernel updates are deployed.
• Where virtio-vsock is not required, unload the vsock and vmw_vsock_virtio_transport modules and blacklist them via /etc/modprobe.d/.
• Limit which user accounts can hold CAP_NET_ADMIN to reduce the set of principals able to attach monitor interfaces.

# Configuration example
# Verify the running kernel and vsock module status
uname -r
lsmod | grep -E 'vsock|vhost_vsock'

# Blacklist vsock modules on hosts that do not require virtio-vsock
cat <<'EOF' | sudo tee /etc/modprobe.d/disable-vsock.conf
blacklist vsock
blacklist vmw_vsock_virtio_transport
blacklist vhost_vsock
EOF

# Remove any existing vsockmon tap interface
sudo ip link show type vsockmon
sudo ip link delete vsockmon0 2>/dev/null || true