CVE-2026-46207

What it actually does

CVE-2026-46207 is a local Linux kernel vulnerability in the virtio vsock monitoring path. When virtio vsock traffic is delivered to the vsockmon tap device, non-linear socket buffers are copied using an incorrectly initialized iov_iter whose count remains zero. As a result, the payload is not copied while the destination buffer may contain uninitialized kernel memory. Depending on how the monitoring interface consumes or exposes that skb, this can cause incorrect monitoring data, potential kernel memory disclosure to a local observer of vsockmon traffic, or instability in components expecting valid payload data. The assigned impact is availability-focused, with local access and low attack complexity required.

Why it matters to the business

Systems running affected Linux kernel versions with virtio/vsock functionality may experience kernel-level instability or unreliable virtual socket monitoring under specific local conditions. In virtualized environments that rely on virtio-vsock for host/guest communication or observability, this could disrupt diagnostics, monitoring, or workloads that depend on stable vsock behavior. The current public exploitation likelihood appears low: EPSS is 0.00127, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity. However, because this is kernel-level code, affected systems should still be patched during normal kernel maintenance windows, especially on virtualization hosts, guest images, and container/VM platforms that enable vsock or vsock monitoring.

How an attack unfolds

An attacker would first need local access to a system where the affected Linux kernel code is present and virtio vsock monitoring is enabled or reachable. They would then generate or influence virtio-vsock traffic that is represented as a non-linear skb. When the kernel attempts to build an skb for the vsockmon tap device, the vulnerable copy path initializes the iterator incorrectly, resulting in a zero-length payload copy. The resulting tap skb may contain empty or uninitialized payload data. A practical attack would depend on the attacker being able to trigger repeated non-linear vsock packets and observe or cause processing of the malformed monitoring packets. Based on the available description and scoring, this is not a remote unauthenticated compromise path; it is a local kernel bug with likely impact to availability and correctness of monitoring behavior.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the virtio vsock skb copy logic. The fix removes the separate non-linear skb copy path and uses skb_copy_datagram_iter() with a properly initialized iov_iter_kvec() for both linear and non-linear buffers. No exact fixed package versions were provided, so remediation should follow the fixed kernel packages from the operating system or distribution vendor. Prioritize virtualization hosts, guest images, appliances, and cloud images where CONFIG_VSOCKETS, virtio-vsock, vhost-vsock, or vsock monitoring may be enabled. If immediate patching is not possible, reduce exposure by disabling unneeded vsock/vsockmon functionality, preventing untrusted local users from accessing vsock-related interfaces, and limiting diagnostic or packet-capture tooling that consumes vsockmon traffic.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package contains the vendor fix for the virtio vsock non-linear skb copy issue. Use distribution advisories, kernel changelogs, or source inspection to confirm the presence of the updated implementation using skb_copy_datagram_iter() with iov_iter_kvec() in the virtio vsock skb build path and the removal or non-use of virtio_transport_copy_nonlinear_skb(). Validate that all running systems have rebooted into the updated kernel, not merely installed it. Check whether vsock-related modules are loaded using commands such as lsmod | grep -E 'vsock|vhost_vsock|virtio_vsock' and verify that unnecessary modules or monitoring interfaces are disabled where not required. For exposure assessment, inventory kernels across virtualization hosts and guests and compare them against vendor-fixed releases.

Typical attack path

1. Gain local user-level access to a Linux system or guest where virtio/vsock support and the vulnerable kernel code are present.
2. Identify whether vsock monitoring through the vsockmon tap device is available or can be triggered.
3. Generate virtio-vsock traffic that results in non-linear socket buffers.
4. Trigger the vulnerable virtio_transport_build_skb() path used to copy payloads for vsockmon delivery.
5. Cause the kernel to produce tap skbs with missing or uninitialized payload contents.
6. Attempt to leverage the malformed monitoring data for denial of service, instability, or unintended exposure depending on local permissions and observability configuration.

How to detect it

There are no public, CVE-specific exploitation indicators for this issue, and exploitation would likely appear as local activity that triggers unusual virtio-vsock or vsockmon behavior rather than a distinctive network signature. Review kernel logs, system journals, crash dumps, and hypervisor or guest telemetry for vsock-related warnings, kernel oopses, BUG/WARN messages, unexpected reboots, or monitoring packets with empty payloads during periods of local user activity. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash/kdump artifacts, auditd records for module loading or access to packet-capture interfaces, and EDR telemetry showing local tooling that generates high-volume AF_VSOCK traffic. If packet capture or observability tooling records vsockmon data, look for abnormal sequences of vsock monitor events where non-zero-length communication is expected but captured payloads are empty. Because no known threat actors or campaigns are associated with this CVE, detection should focus on anomaly hunting and post-crash forensics rather than fixed attacker infrastructure.

• virtio_transport_build_skb
• virtio_transport_copy_nonlinear_skb
• skb_copy_datagram_iter
• iov_iter_kvec
• vsockmon
• vhost_vsock
• virtio_vsock
• AF_VSOCK
• kernel: BUG
• kernel: WARNING
• kernel oops
• general protection fault
• unable to handle kernel
• /var/log/kern.log
• /var/log/messages
• /proc/net/vsock

What your security team should do

• Inventory Linux systems, virtualization hosts, guest images, and appliances that use virtio-vsock, vhost-vsock, or vsock monitoring.
• Track the relevant Linux distribution advisories and upgrade affected kernels to the vendor-fixed release when available.
• Prioritize patching systems with untrusted local users, multi-tenant virtualization, CI runners, developer workstations running VMs, or workloads that expose vsock functionality to less-trusted code.
• Ensure systems are rebooted into the fixed kernel after patch installation.
• Disable or restrict vsock/vsockmon functionality where it is not operationally required.
• Monitor kernel logs for crashes, warnings, or anomalous vsock-related behavior until patching is complete.
• Treat exploitation risk as currently low but not negligible because the vulnerable code is in the kernel and can be reached locally under specific virtualization conditions.