CVE-2026-46234

What it actually does

This Linux kernel flaw affects the vsock buffer size update logic. The vulnerable code clamps the requested buffer size to the configured maximum before applying the configured minimum; if the minimum is set higher than the maximum, the later minimum check can override the maximum and allow vsk->buffer_size to exceed vsk->buffer_max_size. Because vsock is used for host-to-guest and inter-VM communication, a local attacker with the ability to create or manipulate vsock sockets and related buffer settings may be able to bypass intended socket memory limits, potentially leading to memory corruption, kernel instability, denial of service, or other high-impact local compromise outcomes depending on kernel configuration and reachable code paths.

Why it matters to the business

Successful exploitation could allow a low-privileged local user or compromised workload to destabilize a Linux host or virtualized environment, potentially causing service outages or enabling deeper system compromise. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so broad exploitation is not indicated; however, the CVSS score is high and the affected component is in the Linux kernel, making remediation important for multi-user systems, virtualization hosts, CI/CD runners, container platforms, and environments where untrusted code can execute locally.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system, such as access to a shell, a compromised application process, or execution inside a workload that can interact with AF_VSOCK. The attacker then attempts to create or use vsock sockets and manipulate buffer sizing behavior so that the configured minimum buffer size exceeds the maximum. Due to the incorrect clamping order, the kernel may accept a buffer size above the intended maximum. The attacker can then exercise the socket path to force excessive or unexpected memory use in the kernel. Depending on the surrounding kernel state, configuration, and allocator behavior, this may result in kernel memory corruption, a system crash, denial of service, or a possible path toward privilege escalation. There is no indication from the supplied data that public exploit code or active exploitation is currently available.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the vsock buffer size clamping order. Because no exact fixed package versions were provided, use the vendor advisory for each distribution or appliance to identify the corrected kernel build. Prioritize systems that permit local shell access, run untrusted workloads, host virtual machines, support containerized multi-tenant workloads, or rely on vsock for host-guest communication. Where immediate patching is not possible, reduce exposure by limiting local user access, disabling or restricting workloads that can use AF_VSOCK where operationally feasible, applying least privilege to containers and virtualized workloads, and using kernel hardening controls such as LSM policies, seccomp, and workload isolation. A reboot is typically required after kernel package updates to ensure the fixed kernel is running.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version, not only the installed package version, matches a vendor release that includes the vsock clamping fix. On Linux systems, compare `uname -r` with the fixed kernel version from the relevant distribution advisory and confirm the system has been rebooted into the updated kernel. Review package-manager history to ensure the kernel update was installed successfully. If source-based validation is possible, confirm that `vsock_update_buffer_size()` clamps the minimum first and then the maximum, ensuring `vsk->buffer_size` cannot exceed `vsk->buffer_max_size`. Validate exposure by checking whether the kernel has vsock support enabled and whether local users, containers, guests, or workloads can create AF_VSOCK sockets.

Typical attack path

1. Obtain local execution on an affected Linux system with low privileges.
2. Confirm that the kernel includes the vulnerable vsock implementation and that AF_VSOCK functionality is available.
3. Create or interact with vsock sockets from user space or a reachable workload context.
4. Manipulate vsock buffer sizing so the configured minimum can exceed the configured maximum.
5. Trigger vsock buffer update behavior that applies the maximum clamp before the minimum clamp.
6. Cause the effective vsock buffer size to exceed the intended maximum boundary.
7. Exercise the socket path to induce excessive kernel memory use, instability, memory corruption, or potentially further local compromise.

How to detect it

There are no unique, reliable indicators of compromise for this vulnerability from the supplied information. Investigation should focus on signs of local exploitation attempts and kernel instability around vsock usage. Review kernel logs, system journal entries, audit logs, EDR telemetry, crash dumps, and hypervisor or guest communication logs for unusual AF_VSOCK activity, kernel warnings involving vsock, unexpected OOM conditions, general protection faults, kernel panics, soft lockups, suspicious local binaries that create vsock sockets, and unexplained service restarts or host reboots. On systems with auditd or eBPF telemetry, look for untrusted processes repeatedly creating sockets with the AF_VSOCK address family or exercising unusual socket buffer behavior. If crash dumps are available, inspect kernel stack traces for vsock functions such as `vsock_update_buffer_size`, `virtio_transport`, `vmci_transport`, or `vhost_vsock`. Absence of these artifacts does not prove non-exploitation, because a successful local exploit may leave few durable traces beyond process activity and kernel instability.

• AF_VSOCK
• vsock_update_buffer_size
• vhost_vsock
• virtio_transport
• vmci_transport
• kernel panic
• general protection fault
• BUG: kernel NULL pointer dereference
• Out of memory: Killed process
• soft lockup
• watchdog: BUG: soft lockup
• vsock

What your security team should do

• Inventory Linux systems and appliances with kernels that include vsock support, especially virtualization hosts, guest systems, developer workstations, CI runners, and container platforms.
• Prioritize patching on systems where untrusted or semi-trusted users can execute local code.
• Track vendor advisories for the exact fixed kernel package versions because no fixed versions were supplied in the input.
• After updating, reboot affected systems and verify the running kernel with `uname -r`.
• If patching is delayed, restrict local access and reduce workload privileges that allow interaction with AF_VSOCK or broad kernel attack surface.
• Monitor for abnormal local process behavior involving vsock sockets, kernel warnings, OOM events, crashes, or unexpected reboots.
• Because there is no known KEV listing, ransomware association, or public exploit maturity in the supplied data, treat this as important kernel hardening work rather than an emergency internet-scale exploitation event.