Security researchers disclosed a serious privilege-escalation issue that centers on the OVSwrap Linux kernel bug—a memory corruption flaw affecting the Linux kernel’s Open vSwitch datapath. In practical terms, the bug can provide local users on a wide range of default-configured systems with a path to root privileges.
The vulnerability is tracked as CVE-2026-64531, carries a CVSS score of 7.8, and was codenamed OVSwrap by the researcher who reported it. Asim Manizada disclosed the issue on July 28, 2026.
Below is what you need to know: how it works at a high level, which systems are at risk, and the most effective mitigation steps while waiting for patched vendor kernels.
What the OVSwrap Linux kernel bug targets
Unlike many Open vSwitch issues that involve userspace components, this one lives in the kernel datapath. The affected code path is not inside the ovs-vswitchd daemon. That distinction matters because it changes both the assumptions an attacker can make and the kinds of defenses that are most relevant.
Manizada’s analysis emphasizes that an attacker does not need existing Open vSwitch bridges, does not need the ovs-vswitchd process to be running, and does not require the host-level CAP_NET_ADMIN capability.
How a local user can reach root
The exploitation path relies on features that are common in modern Linux environments: access to unprivileged user namespaces and availability of the Open vSwitch kernel datapath.
On systems where unprivileged user namespaces are enabled, an ordinary user can create private user and network namespaces using unshare -Urn. After entering that namespace context, the attacker can obtain CAP_NET_ADMIN inside the namespace and then reach the vulnerable flow-installation logic.
The bug also has an important operational twist: if the openvswitch kernel module is installed but not loaded, simply resolving its Generic Netlink family name can trigger automatic module loading. As a result, an empty lsmod output is not proof that you are safe.
Why the flaw exists: a wrapped length in generated actions
At the core of the OVSwrap Linux kernel bug is a length-handling mistake in how Open vSwitch stores generated flow actions. Internally, the system represents generated flow actions as Netlink attributes, and the attribute length field (nla_len) is 16 bits wide. That effectively caps the size of a nested attribute at 65,535 bytes.
Even though the underlying truncation behavior reportedly existed for years, a separate 32 KiB total cap on the generated action stream prevented nested actions from reaching the wrap point. Later, a change made in March 2025 removed that cap to improve reliability, but it also unintentionally exposed the older truncation issue from a security perspective.
Manizada described the outcome as a memory corruption vulnerability with “logic-bug-grade reliability.” The exploit mechanics do not depend on fragile timing. Instead, they leverage deterministic parsing behavior once the wrapped length is created.
What happens during parsing
An attacker can craft a CLONE action containing hundreds of conntrack sub-actions. On x86-64 systems, each sub-action expands to roughly 164 bytes. With enough sub-actions, the resulting nested action can exceed 65,535 bytes and cause the 16-bit length field to wrap when Open vSwitch writes it.
Subsequent code trusts that wrapped length and resumes parsing from a location that the attacker can influence. Because the landing point is deterministic inside the same contiguous buffer, the attacker can proceed without elaborate heap grooming.
Exploit chaining: from corruption to credentials
The published proof-of-concept (PoC) reported by Manizada is not described as a harmless demonstration—it is explicitly destructive. It also assumes additional Open vSwitch and conntrack-related capabilities on the system.
According to the disclosure, the exploit chains multiple primitives that build on the wraparound issue:
- Kernel pointer leak via a fake OUTPUT action
- Arbitrary kernel read via a forged tunnel SET action
- Targeted decrement through teardown of a forged tun_dst pointer
With those primitives, the exploit aims to locate a host process’s credentials. On modern kernels, it can then decrement fsuid and fsgid to zero, effectively turning the process into root.
Extra dependencies and requirements
The PoC also requires specific environment components: OVS conntrack support, the FTP conntrack helper, and sudo installed.
For successful compromise, the exploit can corrupt live kernel credential data and then alter system authorization files such as /etc/sudoers.d or /etc/sudoers. It can then open a root shell. The PoC is designed to leave behind kernel and Open vSwitch state deliberately to avoid unsafe teardown behavior.
Releases, affected versions, and why your vendor kernel matters
Upstream fixes were included in stable trees on July 24. However, this announcement also stresses that upstream version numbers are not sufficient for real-world risk assessment.
The first fixed upstream releases listed are: Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5.
Additionally, end-of-life series 6.13 through 6.17, 6.19, and 7.0
Which distributions were reported as exploitable
Manizada tested a broad set of environments using a non-exhaustive matrix and reported default-config exploitation on multiple systems. The list includes (among others) 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, and Rocky Linux 9 and 10, as well as Ubuntu 22.04.
On Ubuntu 24.04, AppArmor blocked direct namespace creation, but the PoC used an aa-exec -p trinity fallback to regain reachability. For Ubuntu 26.04, the ordinary-user route was blocked; disabling an AppArmor user-namespace restriction made the tested systems exploitable.
Manizada also notes that Ubuntu 20.04, Debian 11, Rocky Linux 8, and Amazon Linux 2 kept older code paths and were not exploitable through the discussed route.
Mitigations you can take now
If you have not yet confirmed whether your vendor kernel is patched, treat this as an urgent risk—especially on multi-user systems or environments where untrusted workloads share a host.
Here are the most practical mitigation steps described in the disclosure.
1) Install a patched vendor kernel
Where available, the strongest fix is to update to a vendor kernel that includes the upstream stable fix. Because distributions may backport changes, always check the vendor’s advisory rather than relying only on upstream version numbers.
2) Block Open vSwitch module loads (interim step)
Where Open vSwitch is not required, you can block future attempts to load the module. The guidance includes creating a modprobe rule, for example:
echo ‘install openvswitch /bin/false’ > /etc/modprobe.d/ovswrap.conf
Keep in mind: if the module is already loaded, blocking future loads is not enough. You still need to unload the module or reboot.
3) Disable unprivileged user namespaces
Disabling unprivileged user namespaces closes the straightforward “ordinary local user” route described for the OVSwrap Linux kernel bug. However, the disclosure cautions this does not automatically protect against scenarios where another process already has CAP_NET_ADMIN over an attacker-controlled network namespace.
Manizada described the container direction as theoretically reachable but not shown in the released PoC. Still, reducing the ability for local users to create namespaces is an important hardening measure.
4) Use the vendor emergency guidance when applicable
The advisory also references emergency protections such as a BPF guard in the PoC repository for environments that must keep both Open vSwitch and namespaces active. If you run mixed security requirements, check whether your environment supports such additional guardrails and whether your vendor recommends an equivalent control.
Why shared hosts face higher impact
The risk is especially acute on systems where multiple users or untrusted workloads share the same machine. In that context, an attacker may already have foothold on one account and then use the OVSwrap Linux kernel bug to expand control into a full-server compromise.
This is also why the recommended mitigations focus on removing the vulnerable conditions: patching the kernel, blocking Open vSwitch when not needed, and reducing namespace capabilities for untrusted users.
Conclusion
The OVSwrap Linux kernel bug (CVE-2026-64531) is a kernel-level memory corruption issue in the Open vSwitch datapath that can enable local users to gain root privileges under certain default configurations. Because it can trigger module loading and because the exact protection depends on vendor backports, you should act immediately: verify the patch status in your distribution’s tracker, install updates where available, and apply interim mitigations such as blocking Open vSwitch module loads or disabling unprivileged user namespaces.
If you’d like, share your Linux distribution and kernel version, and I can help you outline a practical checklist to validate exposure and prioritize remediation.
Source: https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html
