CVE-2026-46234: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-46234 Overview

CVE-2026-46234 is a Linux kernel vulnerability in the virtual socket (vsock) subsystem. The flaw exists in the vsock_update_buffer_size() function, which clamps the requested buffer size in the wrong order. The implementation applies the maximum bound before the minimum, allowing a user-supplied minimum that exceeds the configured maximum to invert the constraint.

When exploited, this allows vsk->buffer_size to grow beyond vsk->buffer_max_size, breaking the intended socket memory boundaries. The issue affects Linux kernel builds with vsock support, commonly used for guest-to-host communication in virtualization platforms such as KVM, VMware, and Hyper-V.

Critical Impact

Local users can cause socket buffers to exceed configured maximum size limits, breaching kernel memory accounting boundaries in the vsock subsystem.

Affected Products

• Linux kernel (vsock subsystem)
• Distributions shipping affected kernel versions prior to the referenced stable patches
• Virtualization hosts and guests relying on vsock for inter-VM communication

Discovery Timeline

• 2026-05-28 - CVE-2026-46234 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46234

Vulnerability Analysis

The vulnerability resides in vsock_update_buffer_size() inside the Linux kernel vsock subsystem. The function is responsible for adjusting the per-socket buffer size while keeping it within the bounds defined by vsk->buffer_min_size and vsk->buffer_max_size. The original implementation clamps the value to the maximum first, then to the minimum.

When a user sets buffer_min_size to a value larger than buffer_max_size, the second clamp overrides the first. The minimum bound effectively raises the buffer size above the configured maximum. This inverts the intended constraint and breaks the socket memory accounting model.

Root Cause

The root cause is incorrect ordering of bounds checks, a logic flaw classified under improper input validation. The function should validate the lower bound first, ensuring the requested size is not below the minimum, and then enforce the upper bound to clamp it at the maximum. Reversing this order allows a larger-than-maximum minimum to dominate the final result, leaving vsk->buffer_size exceeding vsk->buffer_max_size.

Attack Vector

A local user with permission to create and configure AF_VSOCK sockets can trigger the flaw by setting socket options that raise the minimum buffer size above the configured maximum. Once the inverted clamp takes effect, the kernel allocates buffers larger than intended for that socket. This can be abused to bypass memory accounting limits and pressure kernel memory allocators in shared virtualization environments.

The vulnerability is described in prose only; no public exploit code is referenced in the advisory. See the upstream stable patches for the precise diff: Kernel Patch 0b68881, Kernel Patch 2602f7b, Kernel Patch 310da27, Kernel Patch a998a7e, and Kernel Patch d114bfd.

Detection Methods for CVE-2026-46234

Indicators of Compromise

• Unexpected growth of per-socket buffer memory attributed to AF_VSOCK sockets in /proc/net/sockstat or slabtop output.
• Processes setting unusually large SO_VM_SOCKETS_BUFFER_MIN_SIZE values via setsockopt on AF_VSOCK sockets.
• Kernel memory pressure or OOM events on virtualization hosts using vsock for guest communication.

Detection Strategies

• Audit installed kernel package versions against the fixed stable releases referenced in the upstream patches.
• Use auditd rules to log setsockopt calls on AF_VSOCK sockets that adjust buffer size parameters.
• Correlate user-space activity with kernel slab allocator growth in the vsock slab caches.

Monitoring Recommendations

• Track kernel version inventory across hypervisors and guests to confirm patch deployment status.
• Monitor for anomalous local privilege boundary activity on systems exposing AF_VSOCK to untrusted workloads.
• Alert on sustained increases in vsock buffer memory consumption per process.

How to Mitigate CVE-2026-46234

Immediate Actions Required

• Apply the upstream Linux kernel patches that reorder the clamp logic in vsock_update_buffer_size() to check the minimum before the maximum.
• Update to distribution kernel packages that incorporate the referenced stable commits.
• Restrict access to AF_VSOCK sockets in multi-tenant or untrusted local-user environments until patches are deployed.

Patch Information

The fix reorders the clamp so the minimum bound is enforced first and the maximum bound is enforced last, guaranteeing vsk->buffer_size never exceeds vsk->buffer_max_size. The corrected logic is available in the stable kernel commits 0b68881, 2602f7b, 310da27, a998a7e, and d114bfd. Refer to the Linux stable kernel repository for the canonical diff and backport targets.

Workarounds

• Where patching is not immediately possible, restrict which users and containers can open AF_VSOCK sockets using Linux capabilities, seccomp filters, or LSM policies.
• Disable the vsock and vmw_vsock_* kernel modules on systems that do not require guest-to-host socket communication.
• Apply cgroup memory limits to constrain the impact of buffer over-allocation on shared hosts.

# Example: prevent loading vsock modules on hosts that do not need them
echo 'install vsock /bin/true' | sudo tee /etc/modprobe.d/disable-vsock.conf
echo 'install vmw_vsock_virtio_transport /bin/true' | sudo tee -a /etc/modprobe.d/disable-vsock.conf
echo 'install vmw_vsock_vmci_transport /bin/true' | sudo tee -a /etc/modprobe.d/disable-vsock.conf
sudo rmmod vmw_vsock_virtio_transport vmw_vsock_vmci_transport vsock 2>/dev/null || true