SURIQ
Read the coverage of OVSwrap and you would think this is an Open vSwitch problem. It is not, and that framing is exactly what will leave a lot of servers exposed. The flaw, tracked as CVE-2026-64531 and scored CVSS 7.8, lets any logged-in local user on a default modern Linux box climb to root through a kernel module most administrators never knowingly turned on. The reason it matters this week is not the age of the bug. It is that the guardrail keeping it dormant was quietly removed last year, and a working exploit is now public.
Security researcher Asim Manizada disclosed the issue on July 28, after reporting it to the kernel security team and Open vSwitch maintainers on June 19; the upstream fix landed on July 24. Two outlets, The Hacker News and Security Affairs, describe the same core mechanism. What follows is the defender's read: who is really in scope, why the timing changed, and how you would know if someone reached for this before you patched.
Why did a bug that sat quiet for 13 years turn dangerous now?
The technical root is an integer wrap in a 16-bit size field. Inside the datapath, each generated action is described by a Netlink attribute whose length is recorded in nla_len, and 16 bits can count no higher than 65,535. Build a nested action that grows past that ceiling and the recorded length rolls over to a tiny number. From there the kernel keeps reading from an offset that no longer lines up with the real data, stepping into connection-tracking bytes an attacker gets to shape, and that misalignment is the foothold for corrupting kernel memory.
That unsafe arithmetic sat in the tree for roughly thirteen years without being reachable. According to Security Affairs, a 32 KiB cap added years ago for OpenStack reliability had incidentally kept generated actions well under the wrap threshold, and a change in March 2025 removed that cap as cleanup. Nobody flagged it as a security change, because on its face it was not one. This is the pattern worth taking away, and it is bigger than one CVE: a defensive constant removed because it looks unnecessary can silently re-arm a memory-safety bug that has been latent for a decade. Treat "this limit seems redundant" refactors in parsing and serialization code as security-relevant reviews, not housekeeping.
"We don't run Open vSwitch" is not the safe assumption
Here is the part the headlines bury. The attack does not require an OVS bridge to already exist, the ovs-vswitchd service to be running, or any CAP_NET_ADMIN privilege on the host itself. On a machine where the Open vSwitch datapath module ships in the kernel and unprivileged user namespaces are turned on, a regular user opens a private namespace, picks up CAP_NET_ADMIN inside it, then loads and exercises the module without help. The daemon you never installed is not the requirement. The module shipping with your kernel is.
That reframes the exposed population. This is not a flaw for the subset of shops that operate Open vSwitch. The real vulnerable set is any distribution that ships the datapath module and leaves unprivileged user namespaces on out of the box, which describes most of the modern fleet. Both writeups list the same default-configuration builds as exploitable, and it helps to read them by family rather than as one long roster:
- Red Hat lineage: Rocky Linux 9 and 10, AlmaLinux 9 and 10, CentOS Stream 9 and 10, Fedora 42 through 44, and Amazon Linux 2023.
- Debian lineage: Debian 12 and 13, Ubuntu 22.04, Linux Mint 22.3, and Pop!_OS.
- Independent distributions: Arch, Gentoo, NixOS, openSUSE Tumbleweed, Alpine 3.22 through 3.24, and Kali 2026.1.
Ubuntu 24.04 fell only after an AppArmor restriction was sidestepped. A set of older releases, among them Ubuntu 20.04, Debian 11, Rocky 8, and Amazon Linux 2, could not be exploited by this path at all. If your estate includes multi-tenant boxes, shared build runners, jump hosts, or anything where people you do not fully trust hold a shell, treat it as in scope until you have checked.
Which kernels close it, and which never will
The fix is a patched kernel. Upstream shipped the correction across the maintained stable branches; several end-of-life branches will not get it at all, so a host on one of those needs to move branches rather than wait for a point release.
| Stable branch | First fixed release | Upstream support |
|---|---|---|
| 5.15.x | 5.15.212 | Fixed |
| 6.1.x | 6.1.178 | Fixed |
| 6.6.x | 6.6.145 | Fixed |
| 6.12.x | 6.12.97 | Fixed |
| 6.18.x | 6.18.40 | Fixed |
| 7.1.x | 7.1.5 | Fixed |
| 6.13 to 6.17, 6.19, 7.0 | no upstream fix | End of life |
In upstream terms the correction lands at 6.6.145 on the 6.6 line, 6.1.178 on the long-term 6.1 branch, and 5.15.212 further back; the newer trains pick it up at 6.12.97, then 6.18.40 on the 6.18 series, and 7.1.5. Several dead branches get nothing at all: 6.13 through 6.17, along with 6.19 and 7.0, have aged out of upstream support and will never see a stable fix, so anything pinned there has to move onto a maintained branch or take your distribution's backported build. Check what your vendor has published rather than the mainline number alone, since distributions carry their own patch trains.
How exploitable is this in practice?
Very. This is not a proof of concept that hints at danger and leaves the hard part to the reader. The public exploit ships with prebuilt targeting data for roughly 800 x86-64 kernel builds and attempts to derive what it needs from kernel symbols or BTF for builds it does not already cover, which makes it close to point-and-shoot across a wide range of hosts. Both sources describe the same chain: leak a kernel address, gain a read into kernel memory, then land a precise write that rewrites a running process's stored credentials up to root. Running it is described as destructive, and it leans on connection-tracking being available, the FTP conntrack helper, and sudo present on the box.
At the time of writing there is no confirmation of in-the-wild exploitation and no CISA Known Exploited Vulnerabilities listing for CVE-2026-64531. That is the current state, not a reason to defer. A local-privilege-escalation primitive with commodity targeting is exactly the kind of building block that gets folded into post-compromise tooling quietly, so the useful assumption is that the window between "public exploit" and "used against you" is short.
The blind spot patching leaves, and how to watch it
Patching the kernel closes the hole. It does nothing about the interval before you patched, when the only evidence a local user reached for this is behavioral. If you run detection on your Linux fleet, the signals worth watching are specific: an openvswitch module autoload on a host that has no networking reason to touch Open vSwitch, unprivileged user-namespace creation paired with OVS Netlink activity from an unexpected process, and the FTP connection-tracking helper being present or loaded on a server that never needed it. None of these is malicious on its own; together, on a box where no one operates virtual switching, they are worth a look. This is the difference between knowing you closed a hole and knowing whether anyone tried it first, and it is why endpoint threat hunting on privilege-escalation paths pays off even after the patch ships.
OVSwrap joins a run of recent Linux local-root findings that share a shape: a logged-in user turning a kernel subsystem into a path to root. We saw it with the XFS filesystem flaw in RefluXFS, with the container-boundary bypass in GhostLock, and with the graphics-server memory corruption in Xorg and XWayland. The common thread is worth internalizing: on a multi-tenant Linux host, every kernel subsystem an unprivileged user can reach is part of your privilege-escalation attack surface, whether or not you deliberately use it.
Patch the kernel, then decide what user namespaces are worth to you
Do these in order. First, patch to a fixed kernel from the table above or your distribution's backported build, and prioritize any host where untrusted users hold shell access. Second, where you cannot patch immediately and the host has no need for Open vSwitch, prevent the module from loading, for example by adding install openvswitch /bin/false to a file under /etc/modprobe.d/. Third, understand the mitigation asymmetry before you rely on the user-namespace lever. Disabling unprivileged user namespaces closes the ordinary-user route, but it does not stop a container that already holds CAP_NET_ADMIN, so container hosts still need the patched kernel or the module block, not just the sysctl. Weigh the userns change against what breaks: containers, sandboxed browsers, and some CI tooling depend on it. On a shared host with untrusted users the tradeoff usually favors restricting it; on a single-tenant appliance it may not be worth the breakage. Either way, the module blocklist and the patch are the durable fixes, and the namespace setting is the temporary hedge.