Researcher Asim Viladi Oglu Manizada disclosed CVE-2026-64531, nicknamed OVSwrap, on July 28 after coordinating with the Linux kernel security team and the Open vSwitch maintainers. It’s a local privilege escalation in the kernel’s Open vSwitch (OVS) datapath — the in-kernel networking component that backs virtually every cloud, container, and virtualization networking stack running on Linux — and it has sat unexploited in mainline for roughly 13 years. CVSS is 7.8, but the practical bar to exploitation is unusually low: a public proof-of-concept with precomputed offsets for around 800 distinct kernel builds is already circulating.

What happened

The bug lives in the OVS action-validation path, where the kernel parses nested netlink action attributes before installing a flow. A 16-bit length field wraps around when the kernel constructs an oversized nested action; once that happens, the parser resumes reading from inside attacker-controlled bytes it should never have reached. The result is a classic out-of-bounds primitive an attacker can turn into an arbitrary kernel read, then a targeted write.

The root cause traces to an earlier upstream change — commit a1e64addf3ff (“net: openvswitch: remove misbehaving actions length check”) — which removed a 32 KiB internal cap on action size that had previously kept this overflow from ever growing large enough to be exploitable. Removing that guardrail turned a latent bug into a working primitive. The fix landed in stable trees on July 24 as commit 3f1f755366687d051174739fb99f7d560202f60b (“net: openvswitch: reject oversized nested action attrs”), four days before public disclosure.

Why it’s worse than a typical LPE

Most kernel LPEs targeting a specific subsystem require the attacker to already have some foothold in that subsystem — a configured OVS bridge, CAP_NET_ADMIN, a running ovs-vswitchd, or at minimum a privileged container. OVSwrap requires none of that. Exploitation needs only an ordinary, unprivileged local user account. The OVS kernel module simply needs to be loaded — which it is by default across most enterprise Linux distributions, since userspace tools query it to check feature support even when no OVS bridge is ever created.

The public PoC leaks kernel pointers to defeat KASLR, uses the out-of-bounds primitive to get a targeted write into kernel memory, and chains that into full credential corruption — writing a sudoers entry and popping a root shell. Because it ships precomputed heap-layout offsets for roughly 800 kernel build/version combinations across major distributions, an attacker doesn’t need to reverse-engineer a target’s kernel; they just need it to be in the lookup table.

Who’s affected

This is an upstream kernel bug, not a distro-specific patch gap, so exposure spans the whole EL9/EL10 family (RHEL, Rocky, AlmaLinux, CloudLinux) and multiple Debian and Ubuntu releases carrying the vulnerable OVS datapath code. Bare-metal hosts, VM hosts, and any multi-tenant Linux box where untrusted users get shell access are all in scope — this includes shared hosting, CI runners, Kubernetes nodes (OVS underpins CNI plugins like OVN-Kubernetes and Antrea), and any environment where the kernel’s OVS module loads by default regardless of whether OVS itself is actually configured.

Mitigation

  1. Patch first. Apply your distribution’s kernel update carrying commit 3f1f755366687d051174739fb99f7d560202f60b or later. RHEL/CentOS-derivative vendors (Red Hat, Rocky/CIQ, CloudLinux) and Debian/Ubuntu have all shipped or are shipping updated kernel builds — check your vendor’s advisory.
  2. If you can’t patch immediately, block module load. echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf prevents the vulnerable module from loading. This is a stopgap, not a substitute for the kernel update — it will break systems that genuinely depend on OVS.
  3. Audit exposure. Any host granting shell or code-execution access to less-trusted principals — shared CI runners, jump boxes, multi-tenant VM hosts — should be prioritized, since the attack requires nothing beyond a standard local account.
  4. Check for the module even where OVS “isn’t used.” Because the kernel module often loads regardless of active OVS configuration, don’t assume a host is safe just because nobody set up a bridge.

Given the low exploitation bar and the size of the precomputed offset table, treat this as an active local-root risk on any unpatched, multi-user Linux host rather than a theoretical one.