Skip to main content

Linux Kernel CVE-2026-46207

| EUVDEUVD-2026-32834 MEDIUM
Memory Leak (CWE-401)
2026-05-28 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-c7cv-93jx-fc79
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
3.3 LOW
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 10, 2026 - 19:26 vuln.today
CVSS changed
Jun 10, 2026 - 19:22 NVD
5.5 (MEDIUM)
Patch available
May 28, 2026 - 12:01 EUVD
CVE Published
May 28, 2026 - 10:16 nvd
MEDIUM 5.5
CVE Published
May 28, 2026 - 10:16 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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.

AnalysisAI

Uninitialized socket buffer data exposure in the Linux kernel's vsock/virtio transport layer (6.7 and later) corrupts vsockmon tap monitoring output when non-linear skbs are in use. The virtio_transport_copy_nonlinear_skb() function constructs an iov_iter without setting iov_iter.count, causing zero-length copies that leave skb payloads uninitialized on the monitor interface - potentially exposing stale kernel memory to vsockmon consumers. Patched stable releases 6.12.90, 6.18.32, and 7.0.9 are available; no public exploit exists and EPSS stands at 0.02% (5th percentile), placing real-world exploitation risk very low but warranting attention in environments actively using vsockmon debugging.

Technical ContextAI

The vulnerability resides in the Linux kernel's VirtIO VSock transport implementation (net/vmw_vsock/virtio_transport.c), which handles host-guest socket communication in virtualized environments using the VirtIO protocol. The function virtio_transport_build_skb() is responsible for constructing socket buffers (skbs) delivered to the vsockmon tap monitoring interface. Prior to the fix, this function bifurcated its logic: linear skbs were handled directly, while non-linear skbs (those with paged data fragments rather than contiguous memory) were routed through virtio_transport_copy_nonlinear_skb(). That non-linear path manually initialized an iov_iter structure but omitted setting iov_iter.count - leaving it at zero after zero-initialization. As a result, the copy operation transfers zero bytes and the monitor skb's data region contains uninitialized (potentially stale) kernel memory. The fix unifies both paths under skb_copy_datagram_iter() with iov_iter_kvec(), mirroring the approach already used by vhost-vsock. CWE-401 (Missing Release of Memory after Effective Lifetime) is assigned, though the more precise root cause is incomplete initialization of a kernel data structure (closer to CWE-909), not a classic memory leak; this classification may be imprecise.

RemediationAI

Upgrade to a patched Linux kernel: 6.12.90, 6.18.32, or 7.0.9 in their respective stable series, or 7.1-rc4 or later in the mainline series. The upstream fix commits are available at https://git.kernel.org/stable/c/3a3e3d90cbc79600544536723911657730759af3 (and three additional stable-series backlinks in the references) for environments requiring manual backporting. If immediate patching is not feasible and vsockmon monitoring is not required, prevent loading of the vsockmon kernel module by blacklisting it (echo 'blacklist vsock_diag' >> /etc/modprobe.d/blacklist.conf) or by avoiding attachment of tap interfaces to vsock sockets - this eliminates the vulnerable code path entirely. Disabling vsockmon has no impact on normal VirtIO VSock guest-host communication and carries no production traffic trade-off, only loss of socket monitoring capability. Distribution-specific backport status (RHEL, Ubuntu, SUSE, Debian) should be verified via each vendor's security advisories, as no distro-specific advisories were available in the provided references at time of analysis.

Vendor StatusVendor

SUSE

Severity: Low
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected

Share

CVE-2026-46207 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy