"no existing OVS bridge, no running ovs-vswitchd, no host-level CAP_NET_ADMIN."
CVE-2026-64531 (OVSwrap): a brief summary
On July 28, 2026 security researcher Asim Manizada disclosed a Linux kernel memory-corruption flaw in the Open vSwitch (OVS) datapath, tracked as CVE-2026-64531 and codenamed OVSwrap. The issue carries a CVSS score of 7.8. Manizada reported the issue to security@kernel.org and the OVS maintainers on June 19; an upstream fix was included in stable trees on July 24, 2026.
How the bug works: a 16-bit length field and a long history
The flaw sits inside the kernel datapath implementation used by Open vSwitch, not in the userspace ovs-vswitchd daemon. OVS stores generated flow actions as Netlink attributes whose nla_len field is 16 bits wide, limiting any single nested attribute to 65,535 bytes. An unsafe assignment in that code had existed for 13 years without triggering a security failure because a 32 KiB cap on the total generated action stream kept nested attributes below the wrap point.
A March 2025 change removed that 32 KiB cap — a reliability-driven fix intended to avoid unpredictable failures in large deployments — and in doing so exposed the older truncation bug. The enabling commit and its review thread discussed reliability and user-facing failures but did not address the security consequence of removing the guard.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlog →Technical exploitation: wraparound, three primitives, and destructive PoC
Manizada describes the exploitation path as deterministic and reliable: an attacker submits a CLONE action packed with hundreds of conntrack sub-actions. On x86-64, each conntrack expansion is about 164 bytes; the generated nested action grows past 65,535 bytes, wraps when written into the 16-bit field, and later code trusts the wrapped length and resumes parsing inside attacker-controlled conntrack data. Because the landing point is deterministic within a contiguous buffer, the exploit requires no heap grooming.
The released proof-of-concept (PoC) chains three primitives gained from the wraparound: a kernel pointer leak via a fake OUTPUT action, an arbitrary kernel read via a forged tunnel SET action, and a targeted decrement by tearing down a forged tun_dst pointer. Those primitives are used to locate a host process's credentials and, on modern kernels, to decrement fsuid and fsgid to zero. The PoC is explicitly destructive, requires OVS conntrack support, the FTP conntrack helper, and sudo to be installed, and modifies live kernel credentials and sudo configuration on success. The repository includes pre-built records for roughly 800 exact x86-64 kernel builds and attempts dynamic derivation for uncovered builds.
Affected distributions and observed default-config reachability
Manizada's non-exhaustive test matrix found default-config exploitation on a broad set of distributions: AlmaLinux 9 and 10; Alpine 3.22–3.24; Amazon Linux 2023; Arch; CentOS Stream 9 and 10; Debian 12 and 13; Fedora 42–44; Gentoo; Kali 2026.1; Linux Mint 22.3; NixOS; openSUSE Tumbleweed; Pop!_OS; Rocky Linux 9 and 10; and Ubuntu 22.04. Ubuntu 24.04 blocked direct namespace creation via AppArmor, but the PoC's aa-exec -p trinity fallback restored reachability; stock Ubuntu 26.04 blocked the ordinary-user route until its AppArmor user-namespace restriction was disabled. By contrast, tested Amazon Linux 2, Debian 11, Rocky Linux 8, and Ubuntu 20.04 retained older code paths and were not exploitable through the route demonstrated by the PoC.
Mitigations, upstream fixes, and interim steps
The upstream stable fixes first appear in Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5. The end-of-life 6.13–6.17, 6.19, and 7.0 series will not receive upstream stable fixes. Because distribution kernels often contain backports and downstream changes, Manizada warns that vendor trackers are the safer source of truth for whether a given distribution release is patched.
Where a patched vendor kernel is not yet available and Open vSwitch is not required, the recommended interim action is to block future module loads by creating a modprobe override. The exact command shown by the researcher is:
echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf
This prevents future automatic module loads; a module already resident in memory must still be unloaded or the host rebooted. If the openvswitch module is installed but not loaded, resolving its Generic Netlink family name can load it automatically — so an empty lsmod is not proof of safety.
Disabling unprivileged user namespaces will close the ordinary local-user route used in the published PoC, but it does not stop a container or other process that already holds CAP_NET_ADMIN over an attacker-controlled network namespace. Manizada described that container direction as theoretically reachable but did not demonstrate it in the released PoC. For environments that must keep both OVS and namespaces active, the PoC repository also includes an emergency BPF guard.
What this means for cloud and hosting providers, system administrators, and container teams
- Cloud and hosting providers: the risk is acute where multiple users or untrusted workloads share a host; as CloudLinux's advisory put it, "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."
- System administrators: prioritize vendor-patched kernels, or apply the module-block override and reboot to clear resident modules; confirm whether your distribution's kernel includes the upstream fixes or equivalent backports.
- Container and orchestration teams: disabling unprivileged user namespaces will block the ordinary local-user abuse path, but assess whether any workloads already hold CAP_NET_ADMIN in network namespaces and consider the emergency BPF guard if both OVS and namespaces are required.
OVSwrap is, in the researcher's words, a "logic-bug-grade reliability" memory-corruption flaw that leverages long-lived code assumptions exposed by a prior reliability change. The safest immediate step for most operators is to install vendor-patched kernels; where that is not yet possible, block or remove the openvswitch kernel module and tighten namespace and AppArmor controls while monitoring vendor trackers for distribution-specific fixes.
