CVE-2026-23057: Linux Kernel Information Disclosure Flaw

CVE-2026-23057 Overview

A vulnerability has been discovered in the Linux kernel's vsock/virtio subsystem related to improper buffer coalescing in the receive queue. The vsock/virtio component attempts to coalesce buffers in the rx queue by joining a linear skb (with spare tail room) with a subsequent small skb. However, since the introduction of MSG_ZEROCOPY support, the assumption that small skbs will always be linear is no longer valid.

In the zerocopy case, when non-linear skbs are incorrectly coalesced, data is lost and the linear skb is appended with uninitialized kernel memory, potentially leading to information disclosure.

Critical Impact

Uninitialized kernel memory exposure through improper buffer coalescing in vsock/virtio loopback-transport, potentially allowing information leakage from kernel space.

Affected Products

• Linux kernel with vsock/virtio loopback-transport enabled
• Systems utilizing MSG_ZEROCOPY with virtio-based vsock transports
• Linux kernel versions prior to the security patches

Discovery Timeline

• 2026-02-04 - CVE CVE-2026-23057 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2026-23057

Vulnerability Analysis

The vulnerability resides in the vsock/virtio common code that handles buffer coalescing within the receive queue. The coalescing logic operates under the assumption that when a linear skb with spare tail room is followed by a small skb (with length limited by GOOD_COPY_LEN = 128), the small skb will always be linear. This assumption was valid prior to MSG_ZEROCOPY support being introduced.

With MSG_ZEROCOPY enabled, non-linear skbs can now appear in positions where linear skbs were previously expected. When the coalescing logic encounters this scenario, it fails to properly handle the non-linear skb data, resulting in data loss from the original skb and appending uninitialized kernel memory to the linear skb instead.

Of the three supported virtio-based transports, only loopback-transport is affected. G2H virtio-transport is safe because its rx queue operates on explicitly linear skbs via virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2G vhost-transport may allocate non-linear skbs, but only for sizes exceeding coalescence thresholds as determined by PAGE_ALLOC_COSTLY_ORDER in virtio_vsock_alloc_skb().

Root Cause

The root cause is a missing linearity check in the buffer coalescing logic. The code assumed all small skbs eligible for coalescing would be linear, but MSG_ZEROCOPY support introduced the possibility of small non-linear skbs. The fix ensures that only linear skbs are coalesced by verifying that skb_tailroom(last_skb) > 0, which guarantees the skb is linear before attempting coalescing operations.

Attack Vector

An attacker could potentially exploit this vulnerability through local access to a system with vsock/virtio loopback-transport enabled. By crafting specific MSG_ZEROCOPY operations, an attacker might trigger the improper coalescing behavior, potentially causing uninitialized kernel memory to be exposed to userspace. This could lead to information disclosure of sensitive kernel data.

The vulnerability requires local access and the ability to interact with vsock interfaces using zerocopy messaging. Systems using vsock/virtio for inter-VM communication in virtualized environments may be at particular risk if loopback-transport is utilized.

Detection Methods for CVE-2026-23057

Indicators of Compromise

• Unexpected behavior or data corruption in vsock/virtio communications
• Memory disclosure patterns in network traffic involving vsock interfaces
• Kernel log messages related to skb handling anomalies in virtio_vsock modules
• Applications using MSG_ZEROCOPY with vsock experiencing data integrity issues

Detection Strategies

• Monitor kernel logs for warnings or errors related to vsock/virtio buffer handling
• Implement memory sanitization checks to detect potential uninitialized memory access
• Deploy kernel-level monitoring for anomalous skb coalescing patterns
• Use SentinelOne's kernel-level visibility to detect exploitation attempts targeting vsock subsystems

Monitoring Recommendations

• Enable kernel auditing for vsock-related system calls and operations
• Configure SentinelOne agents to monitor for suspicious vsock/virtio activity patterns
• Track usage of MSG_ZEROCOPY flag in applications interacting with vsock interfaces
• Monitor for unexpected memory access patterns that may indicate kernel information leakage

How to Mitigate CVE-2026-23057

Immediate Actions Required

• Review systems for vsock/virtio loopback-transport usage and assess exposure
• Apply the kernel patches from the official Linux kernel git repository
• Consider disabling MSG_ZEROCOPY support if not required until patches are applied
• Restrict local access to vsock interfaces on affected systems

Patch Information

The Linux kernel development team has released patches to address this vulnerability. The fix ensures that only linear skbs are coalesced by adding proper linearity verification. The patches are available through the official kernel git repository:

• Kernel Git Commit Update
• Kernel Git Commit Fix
• Kernel Git Commit Change

Update to a kernel version containing these commits to fully remediate the vulnerability.

Workarounds

• Disable vsock/virtio loopback-transport if not required for operations
• Avoid using MSG_ZEROCOPY flag with vsock interfaces on unpatched systems
• Implement network segmentation to limit exposure of vsock interfaces
• Apply kernel hardening measures to reduce the impact of potential memory disclosure

# Check if vsock modules are loaded
lsmod | grep vsock

# Temporarily disable vsock modules if not required (requires root)
modprobe -r vmw_vsock_virtio_transport
modprobe -r vsock_loopback

# Verify current kernel version
uname -r

# Check for available kernel updates on Debian/Ubuntu
apt update && apt list --upgradable | grep linux

# Check for available kernel updates on RHEL/CentOS
yum check-update kernel