A memory corruption vulnerability in the Linux kernel's Open vSwitch datapath allows unprivileged local users to escalate privileges to root across a wide range of default-configured distributions, and a publicly available exploit includes pre-built records for roughly 800 kernel builds. The flaw, tracked as CVE-2026-64531 and nicknamed OVSwrap, was disclosed by security researcher Asim Manizada on July 28, 2026. The bug resides in the kernel datapath itself, not in the userspace daemon, and on vulnerable systems with the OVS kernel datapath available and unprivileged user namespaces enabled, an ordinary user can reach the vulnerable code path without needing an existing OVS bridge, a running daemon, or host-level network administrator capabilities.

The vulnerability affects a broad swath of distributions tested by Manizada, including AlmaLinux 9 and 10, Alpine 3.22 through 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 and 10, Debian 12 and 13, Fedora 42 through 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 and 10, and Ubuntu 22.04 in default configurations. Ubuntu 24.04 systems saw AppArmor block direct namespace creation, though a fallback technique restored exploitability; stock Ubuntu 26.04 blocked the ordinary-user route, but disabling its AppArmor user-namespace restriction made tested systems vulnerable. Tested Amazon Linux 2, Debian 11, Rocky Linux 8, and Ubuntu 20.04 retained older code paths and weren't exploitable through this vector. The upstream fix shipped in stable trees on July 24, with the first corrected releases being Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5, while end-of-life series 6.13 through 6.17, 6.19, and 7.0 won't receive upstream stable patches.

According to Manizada's technical write-up, an attacker requires "no existing OVS bridge, no running ovs-vswitchd, no host-level CAP_NET_ADMIN" to exploit the flaw on affected systems. The researcher reported the issue to security@kernel.org and the OVS maintainers on June 19, 2026. Manizada described the result as a memory corruption vulnerability with "logic-bug-grade reliability," and warned that an empty lsmod output doesn't mean a system is safe, since resolving the Generic Netlink family name can automatically load the openvswitch module even if it wasn't previously loaded.

The root cause lies in how Open vSwitch stores generated flow actions as Netlink attributes, where the nla_len field is 16 bits wide, capping any single nested attribute at 65,535 bytes. The unsafe assignment had existed for 13 years, but a 32 KiB cap on the total generated action stream kept nested actions below the wrap point. A March 2025 change removed that cap because it produced unpredictable failures in large OpenStack deployments, exposing the older truncation bug; the enabling commit's review thread discussed reliability and user-facing failures but didn't address the security consequence of removing the safeguard. An attacker submits a CLONE action packed with hundreds of conntrack sub-actions, and on x86-64, the kernel expands each one to 164 bytes, pushing the generated nested action past 65,535 bytes and causing the value to wrap when written into the 16-bit length field. Later code trusts that length and resumes parsing from inside attacker-controlled conntrack data, where forged OVS actions are waiting, and because the landing point is deterministic inside the same contiguous buffer, no heap grooming is required.

Where a patched vendor kernel isn't yet available and Open vSwitch isn't required, the report recommends blocking future module loads with a modprobe override that prevents the openvswitch module from loading; if the module is already resident in memory, it must be unloaded or cleared by rebooting. Disabling unprivileged user namespaces closes the ordinary local-user route but doesn't block a container or other process that already has network administrator capabilities over an attacker-controlled network namespace. The risk is especially acute where multiple users or untrusted workloads share a host, as CloudLinux's advisory noted: the local user in that scenario may be an attacker who already compromised one site through an unrelated flaw, and OVSwrap is what turns that single-account problem into a whole-server one. Environments that preserve tight separation between user contexts face lower immediate risk, but the reliability of the exploit and the breadth of affected distributions make patching the urgent priority for any multi-tenant or shared-hosting environment. The thirteen-year lifespan of the dormant flaw underscores how reliability improvements can inadvertently awaken latent security defects, and the gap between upstream fixes and vendor kernel availability creates a narrow window where interim mitigations become the only defense.