CVE-2026-23057: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-23057 Overview

CVE-2026-23057 is a Linux kernel vulnerability in the vsock/virtio common code path. The flaw resides in the receive queue buffer coalescing logic, which incorrectly assumes that small socket buffers (skbs) are always linear. After the introduction of MSG_ZEROCOPY support, this assumption no longer holds. Coalescing a non-linear zerocopy skb into a preceding linear skb causes data loss and appends uninitialized kernel memory to the resulting buffer.

The issue affects the loopback transport. The G2H (guest-to-host) virtio-transport and H2G (host-to-guest) vhost-transport paths are not affected because of how they allocate receive buffers.

Critical Impact

Local processes communicating over AF_VSOCK loopback may receive uninitialized kernel memory contents in place of intended payload bytes, creating an information disclosure primitive.

Affected Products

• Linux kernel versions supporting vsock/virtio with MSG_ZEROCOPY
• Systems using AF_VSOCK loopback transport (vsock_loopback)
• Virtualization hosts and guests relying on virtio-vsock for inter-VM communication

Discovery Timeline

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

Technical Details for CVE-2026-23057

Vulnerability Analysis

The vsock/virtio common layer attempts to reduce receive queue fragmentation by coalescing buffers. When a linear skb in the rx queue has spare tail room and is immediately followed by a small skb whose length is bounded by GOOD_COPY_LEN (128 bytes), the kernel copies the small skb's data into the tail room of the preceding linear skb.

The coalescing routine reads from the small skb's linear data area using skb->data and copies skb->len bytes. This is safe only when the source skb is fully linear. With MSG_ZEROCOPY, the producer can build skbs whose payload lives in page fragments rather than the linear header area. In that case, the source linear area does not contain the payload, and the copy ingests uninitialized or stale kernel memory adjacent to the skb head.

Among the three virtio-based transports, only loopback is affected. The G2H virtio path uses virtio_vsock_alloc_linear_skb() inside virtio_vsock_rx_fill(), guaranteeing linearity. The H2G vhost path may produce non-linear skbs through virtio_vsock_alloc_skb() only for sizes exceeding PAGE_ALLOC_COSTLY_ORDER, which are above the coalescing threshold and therefore never merged.

Root Cause

The root cause is an invalid linearity assumption in the coalescing path [CWE-908: Use of Uninitialized Resource]. Code introduced before MSG_ZEROCOPY support presumed that any skb shorter than GOOD_COPY_LEN carried its full payload in the linear region. The zerocopy path violates this invariant by placing payload bytes in fragment pages while leaving the linear region empty.

Attack Vector

A local process with permission to open AF_VSOCK sockets can construct a sender that uses MSG_ZEROCOPY to transmit small messages over the loopback transport. The receiver observes uninitialized kernel memory appended to a previous message instead of the expected payload. Repeated transmissions can be used to harvest fragments of kernel memory, potentially leaking sensitive data such as pointers, credentials, or cryptographic material that aids further exploitation.

The upstream fix enforces that only linear skbs are eligible for coalescing. The patch relies on the property that skb_tailroom(last_skb) > 0 guarantees last_skb is linear, and additionally checks the linearity of the candidate small skb before merging. See the kernel commits referenced under Linux Kernel Commit 0386bd32, Commit 568e9cd8, and Commit 63ef9b30.

Detection Methods for CVE-2026-23057

Indicators of Compromise

• Unexpected non-zero, non-payload bytes appearing at the tail of received AF_VSOCK messages on the loopback transport.
• Unprivileged processes loading or exercising the vsock_loopback kernel module on production hosts where vsock is not a documented requirement.
• Application-layer parsers reporting corrupted or oversized records on vsock channels that previously operated cleanly.

Detection Strategies

• Audit kernel versions across the fleet and flag hosts running unpatched kernels that ship the vsock_loopback module.
• Use auditd or eBPF tooling to log socket(AF_VSOCK, ...) calls combined with setsockopt invocations enabling SO_ZEROCOPY.
• Correlate vsock socket activity from non-virtualization workloads, since most legitimate use cases involve hypervisor or VM agents.

Monitoring Recommendations

• Track loading of the vsock, vsock_loopback, and vmw_vsock_virtio_transport_common modules with kernel module load telemetry.
• Alert on processes that combine AF_VSOCK socket creation with MSG_ZEROCOPY send flags on systems that do not require this functionality.
• Monitor for anomalous data patterns on vsock channels using application-side integrity checks where feasible.

How to Mitigate CVE-2026-23057

Immediate Actions Required

• Apply the upstream stable kernel updates that include the three referenced commits restricting coalescing to linear skbs.
• Inventory hosts that load vsock_loopback and prioritize patching systems where untrusted local users can open AF_VSOCK sockets.
• On systems that do not require AF_VSOCK loopback, blacklist the vsock_loopback module to remove the affected code path.

Patch Information

The vulnerability is resolved by the upstream Linux kernel commits 0386bd321d0f, 568e9cd8ed7c, and 63ef9b300bd0. Distribution maintainers backport these to long-term stable trees. Verify the running kernel includes the change by checking that vsock/virtio coalescing now validates linearity of the merge candidate.

Workarounds

• Unload and blacklist the vsock_loopback module on hosts that do not require loopback vsock communication.
• Restrict AF_VSOCK socket creation to trusted users via seccomp policies or LSM rules where application requirements permit.
• Disable MSG_ZEROCOPY in applications that communicate over AF_VSOCK loopback until the kernel is patched.

# Configuration example: disable vsock loopback transport
echo "blacklist vsock_loopback" | sudo tee /etc/modprobe.d/blacklist-vsock-loopback.conf
sudo modprobe -r vsock_loopback

# Verify the module is no longer loaded
lsmod | grep vsock_loopback