CVE-2026-46207: vsock/virtio: fix empty payload in tap skb for non-linear buffers
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: fix empty payload in tap skb for non-linear buffers
For non-linear skbs, virtio_transport_build_skb() goes through
virtio_transport_copy_nonlinear_skb() to copy the original payload
in the new skb to be delivered to the vsockmon tap device.
This manually initializes an iov_iter but does not set iov_iter.count.
Since the iov_iter is zero-initialized, the copy length is zero and no
payload is actually copied to the monitor interface, leaving data
un-initialized.
Fix this by removing the linear vs non-linear split and using
skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as
vhost-vsock already does. This handles both linear and non-linear skbs,
properly initializes the iov_iter, and removes the now unused
virtio_transport_copy_nonlinear_skb().
While touching this code, let's also check the return value of
skb_copy_datagram_iter(), even though it's unlikely to fail.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw affects virtio-vsock monitoring. In some non-linear buffer cases, data intended for the vsock monitor interface was not copied, leaving the monitor packet with uninitialized contents. The source does not provide a CVSS score, confirmed impact beyond that behavior, or evidence of real-world exploitation.
Executive priority
Treat this as a kernel maintenance item until stronger impact evidence appears. Prioritize patching systems that use virtio-vsock monitoring, especially shared virtualization platforms, but do not escalate as actively exploited based on the provided sources.
Technical view
virtio_transport_build_skb() used a separate non-linear skb copy path that initialized an iov_iter without setting count. Because the iterator was zero-initialized, zero bytes were copied to the vsockmon tap skb. The kernel fix removes the split path and uses skb_copy_datagram_iter() with iov_iter_kvec() for both linear and non-linear skbs.
Likely exposure
Exposure is most plausible on Linux systems using virtio-vsock with vsockmon or related monitoring of virtio transport traffic. The provided affected-version data lists Linux kernel versions and stable commits, but does not map them to distributions or cloud images.
Exploitation context
No source in the bundle states active exploitation, and KEV is false. The issue is described as an implementation bug in monitor packet construction, not as a public exploit chain. Practical risk depends on whether untrusted users can access affected vsock monitoring output.
Researcher notes
The core signal is uninitialized data in tap skb delivery for non-linear buffers due to an unset iov_iter.count. The source bundle lacks CVSS, CWE, distribution impact, privilege requirements, and exploitability analysis, so exposure assessment should be validated against actual kernel configuration and monitoring use.
Mitigation direction
Apply vendor kernel updates that include the referenced stable fixes.
If no package is available, follow Linux distribution or kernel vendor guidance.
Prioritize virtualized hosts using virtio-vsock or vsock monitoring.
Limit access to vsock monitoring outputs to trusted administrators.
Track whether your kernel branch contains the relevant stable commit.
Validation and detection
Inventory running Linux kernel versions across virtualized hosts.
Identify systems using virtio-vsock and vsockmon monitoring.
Check vendor advisories for CVE-2026-46207 coverage.
Confirm patched kernels include one referenced stable fix commit.
Review monitoring access controls for least-privilege exposure.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-46207 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 28, 2026, 09:40 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.