OVSwrap (CVE-2026-64531): patch Linux for this local root

On July 28, 2026, researcher Asim Manizada published OVSwrap (CVE-2026-64531), a local root bug in the Linux kernel’s Open vSwitch datapath, with a public write-up and proof-of-concept.

Disclosure: oss-security. Write-up: heyitsas.im/posts/ovswrap.

If you run Linux desktops, cloud VMs, or hypervisors on common distros with the OVS module available and unprivileged user namespaces enabled, treat this as a patch-now item, not a “wait for the monthly window” curiosity.

Mid-July already dumped a pile of kernel CVEs on admins. OVSwrap is the one with a clear local-root story and a public exploit path.

What goes wrong

At a high level (no exploit recipe):

1. OVS accepts a userspace action list, then expands some actions into a larger internal stream stored as Netlink attributes.
2. Netlink’s length field is 16-bit. A March 2025 change removed an old size cap, so a crafted nested action list can expand past 65,535 bytes and wrap that length.
3. Later kernel code trusts the wrapped length, resumes parsing inside attacker-influenced data, and the PoC chain turns that into credential corruption and root execution.

You need the OVS kernel datapath (with conntrack/FTP-helper support present) and either unprivileged user/network namespaces or some other path to CAP_NET_ADMIN in a namespace the attacker controls. AppArmor/SELinux do not stop the exploit once that capability is in hand.

Manizada notes a possible container path with appropriate CAP_NET_ADMIN but did not fully validate escape. That is still enough reason not to hand that capability out casually.

Who is exposed

The oss-security post lists a long set of stock-default exploitable distros when an affected kernel is installed, OVS/conntrack support is present, and unprivileged namespaces are allowed, including current Ubuntu LTS lines, Debian 12/13, Fedora 42+, Alma/Rocky 9/10, Amazon Linux 2023, Arch, and many others.

That list is why this is not “only if you built an OVS lab.” On a lot of distributions the module is available; you do not have to be running a production SDN fabric for the code to be loadable.

Fixed kernels

Upstream stable trees that first include the fix (net: openvswitch: reject oversized nested action attrs):

Series	First fixed release (per disclosure)
5.15	5.15.212
6.1	6.1.178
6.6	6.6.145
6.12	6.12.97
6.18	6.18.40
7.1	7.1.5

Pull your distro’s security kernel, not a random mainline tarball, unless you intentionally run custom kernels. EOL series without backports are a separate risk conversation.

What to do today

1. Inventory Linux hosts (workstations, jump boxes, hypervisors, cloud images). Note kernel version and whether openvswitch is loaded or even present.
2. Patch to a fixed vendor kernel and reboot into it. Confirm uname -r after reboot.
3. If you cannot patch immediately:
   • Unload openvswitch and blacklist it if you do not need OVS.
   • Consider tightening unprivileged user namespaces (know that this alone may not cover every container/CAP_NET_ADMIN path).
   • The researcher published an emergency BPF mitigation with the PoC repo for environments that must keep OVS + userns. Use vendor guidance and your own change control before dropping unknown BPF into production.
4. Containers: Audit pods/VMs that grant CAP_NET_ADMIN or load host OVS modules. Least privilege still matters.
5. Communicate with a short notice: CVE id, exposure condition, and patch status. Not a novel.

Bottom line

CVE-2026-64531 (OVSwrap) is a local root in the Linux OVS datapath with public exploit material as of July 28, 2026. Patch to fixed stables, or remove the OVS attack surface until you can. Kernel CVE noise is high this month; this one earned a place at the top of the queue.