LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

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.
Prepared
Confidence
medium
Sources
6

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux4b0bf10eb077cb43c09746251ef3608d62c45667, 4b0bf10eb077cb43c09746251ef3608d62c45667, 4b0bf10eb077cb43c09746251ef3608d62c45667, 4b0bf10eb077cb43c09746251ef3608d62c45667unaffected
LinuxLinux6.7, 0, 6.12.90, 6.18.32, 7.0.9, 7.1affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.