OVSwrap — Open vSwitch datapath overflow

This tracker is no longer updated. Every tracked distribution has shipped a kernel carrying the 3f1f75536668 backport, or runs a kernel line that predates the regression and was never affected; the in-window lines that ended without the fix (upstream 7.0.y and 6.13.y, and the superseded Proxmox 6.14 series) remain permanently vulnerable, as noted in the sections below.

Summary

How the exploitation chain works

Open vSwitch lets userspace install datapath flows and their actions through a netlink interface. Actions nest: a CLONE action wraps a list of sub-actions, and a conntrack (ct) action carries its own nested attributes. Netlink expresses that nesting with attributes whose length lives in a 16-bit nla_len field — a hard ceiling of 65,535 bytes per attribute.

Historically the datapath capped the total generated action stream at 32 KiB, which kept every nested attribute comfortably under the 16-bit limit. In March 2025 a1e64addf3ff (remove misbehaving actions length check) deleted that cap because it was rejecting legitimate large action sets — but nothing replaced the missing per-attribute bound.

An attacker crafts a CLONE action holding hundreds of conntrack actions. When the datapath copies that nested action list, its serialized length grows past 65,535 bytes and the 16-bit nla_len wraps to a small value. Subsequent parsing trusts the wrapped length and resumes at an incorrect offset inside the attacker-controlled conntrack data, reading and writing structures the length field no longer describes — a heap out-of-bounds the PoC escalates into kernel-pointer leaks, kernel-memory reads, and credential corruption for root.

ℹ️ Reaching this needs three conditions at once: the OVS kernel datapath in active use (the openvswitch module handling flows), conntrack/FTP-helper actions in the flow, and — for an unprivileged trigger — unprivileged user namespaces enabled, since the OVS netlink API needs CAP_NET_ADMIN and a userns grants it inside the namespace. Disabling unprivileged userns removes the unprivileged path but not a caller that already holds CAP_NET_ADMIN. These conditions narrow who can reach the bug but do not fix it — only a patched kernel does — and a kernel below its series’ introducing commit is not affected at all.

Vulnerable commit range

The reachable lifetime runs from v6.14 through v7.1; v7.2-rc4 and the current stable point releases carry the fix. Because this is a 2025 regression, kernels that never received a1e64addf3ff are not affected — see Affected window above for the per-series boundary.

Patch status

Two things decide a row: whether its kernel is in-window (at or above its series’ intro point — see Affected window), and if so whether it carries the 3f1f75536668 backport. The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. First fixed and Fixed since stay — until a row is fixed.

Linux kernel

The fix was committed to the net tree on 2026-07-11 and reached Linus in v7.2-rc4 (tagged 2026-07-19); the kernel CNA backported it across the maintained in-window stable lines on 2026-07-24 (per-branch versions in the table). Two in-window lines ended upstream without the backport: 7.0.y reached end of life at 7.0.14 on 2026-06-27, before the disclosure (Proxmox’s Ubuntu-derived 7.0 kernel lives on and is tracked under Proxmox VE below), and the short-lived 6.13.y line, in-window from 6.13.8, which no tracked distribution ships. A host on either is permanently vulnerable.

Because the cap removal was backported into stable only as far down as the 5.15 line, the 5.10.y line and earlier never received it and are genuinely not affected — the vulnerable code is absent, not merely unpatched.

Debian

Debian is affected only in the suites whose kernel carries the 2025 cap removal. bullseye (LTS) ships the 5.10 series, which predates the regression — the security tracker records “vulnerable code not present” — so its default kernel is not affected, while its opt-in 6.1 kernel (the linux-6.1 source package, bookworm’s kernel rebuilt for bullseye) is in-window — it now carries the fix, having been rebased onto upstream 6.1.180 (above the 6.1.x branch’s 6.1.178 first-fixed release) with no CVE-specific advisory. bookworm gained a second, newer opt-in kernel of its own: linux-6.12 (the trixie 6.12 kernel rebuilt for bookworm, mirroring bullseye’s linux-6.1 pattern) entered bookworm-security already carrying the fix at 6.12.100-1~deb12u1, so it has never been vulnerable in this suite. bookworm, trixie, sid, forky, bullseye’s opt-in linux-6.1, and bookworm’s opt-in linux-6.12 all carry the fix; forky picked it up via 7.1.6-1, having skipped straight past the 7.1.5-1 first-fixed upload. Debian has shipped unprivileged user namespaces enabled by default since bullseye (kernel.unprivileged_userns_clone=1) and does not apply Ubuntu’s AppArmor userns restriction, so on a stock Debian host the unprivileged local vector is open unless an admin disables it.

Proxmox VE

Proxmox ships its own kernels (proxmox-kernel-*), so Debian’s status does not carry over. On 2026-07-28 Proxmox cherry-picked the fix into three series — PVE 9’s 7.0 default (7.0.14-8), its superseded 6.17 series (6.17.13-21), and PVE 8’s 6.8 default (6.8.12-39) — each naming CVE-2026-64531 in the packaging changelog, with the fixed builds published in pve-no-subscription. The 6.8 fix is notable: although the upstream 6.8 base predates the regression, Proxmox’s Ubuntu-derived 6.8 kernel received the cherry-pick — Ubuntu’s heavy backporting carried the vulnerable code in, so a pre-6.14 Proxmox series cannot be assumed safe by version alone.

An opt-in series is Proxmox’s preview of a likely next default; an old series is a superseded default or an opt-in overtaken by a newer one. Proxmox stops updating superseded series after a short transition tail — 6.17 caught the fix inside that tail — and every such series is end-of-life upstream, so a fix there could only arrive as a late Proxmox cherry-pick.

The 6.14 series is no longer updated — its last builds predate the disclosure. PVE 9 launched with 6.14 as its default and superseded it with 6.17 on 2025-11-11; the last 6.14 builds — PVE 9’s 6.14.11-9 and PVE 8’s opt-in rebuild 6.14.11-9~bpo12+1 — date to 2026-05-15, with no OVSwrap cherry-pick then or since. A host still booted into any 6.14 kernel is in-window and permanently vulnerable; move to the release’s current default kernel.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, so all of them are fixed; they differ only in which point release they have reached. Kernel updates land on nixpkgs master first, and each channel publishes them once its Hydra jobset passes. A channel can therefore sit a few days behind master, and an unstable channel is not necessarily ahead of a release channel. The -small channels (nixos-unstable-small, nixos-26.05-small) are gated on a reduced jobset and pick up kernel updates fastest.

The master and release-26.05 rows are the git branches the fix lands on. They are not Hydra-gated, so they carry a kernel bump from the moment the commit lands — typically a day or three before a channel republishes it, which is what the Fixed since dates down the group show. They are development branches, not deployment targets.

Flake inputs map onto these directly. github:NixOS/nixpkgs/nixos-unstable tracks the nixos-unstable channel — the GitHub channel branches are updated to exactly the published channel pins — and a bare github:NixOS/nixpkgs with no ref follows master. A bare nixpkgs registry input resolves by default to nixpkgs-unstable, which is a separate channel aimed at Nix users on other operating systems rather than at NixOS, so it is not gated on the NixOS tests and can hold a different kernel from nixos-unstable.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks with heavily backported feature sets, so the base version alone cannot decide whether the 2025 OVS cap removal is present — Red Hat’s assessment is authoritative, and it arrived on 2026-07-27: EL8 (4.18) is not affected (vulnerable code not present), while EL9 (5.14) and EL10 (6.12.0) were affected. EL9 carries the cap removal as a backport despite its base predating the regression — the same pattern as Proxmox’s Ubuntu-derived 6.8 kernel. Red Hat shipped a first fix on 2026-08-06 (RHSA-2026:51603/51604) for the RHEL 9.2 Extended Update Support stream (kernel-5.14.0-284.186.1.el9_2), followed on 2026-08-07 by RHEL 9.4 (RHSA-2026:51746, kernel-5.14.0-427.143.1.el9_4) and RHEL 9.8 (RHSA-2026:53329, kernel-5.14.0-687.38.1.el9_8) — the last covers the plain kernel package Rocky 9 tracks. On 2026-08-11 Red Hat additionally fixed RHEL 10’s general 10.2.Z stream (RHSA-2026:53330, kernel-6.12.0-211.46.1.el10_2). Rocky rebuilds RHEL’s kernels unchanged, and both rebuilds reached BaseOS the same day, 2026-08-11 — each build’s packaging changelog names CVE-2026-64531 directly — so Rocky 9 and Rocky 10 are now fixed. Each of those advisories also ships the matching kernel-rt real-time build for its stream — RHSA-2026:51604 for 9.2 E4S, folded into RHSA-2026:51746 for 9.4 E4S, into RHSA-2026:53329 for 9.8, and into RHSA-2026:53330 for RHEL 10.2 — so a host running kernel-rt is covered by the same update as the plain kernel package; it carries no separate row. Oracle Linux and CloudLinux OS track the RHEL determination.

Amazon Linux

Amazon shipped one ALAS per AL2023 kernel stream, all issued 2026-07-27: ALAS2023-2026-2005 fixed the default kernel package (a 6.1-series stream) at 6.1.176-223.369.amzn2023, ALAS2023-2026-2004 fixed the kernel6.12 opt-in at 6.12.94-123.192.amzn2023, and ALAS2023-2026-2003 fixed the kernel6.18 opt-in at 6.18.38-76.139.amzn2023. All three streams have since moved past their fixed build and remain fixed.

Detection

Is the running kernel in the affected window and missing the fix? Compare the running kernel against the Patch status table — a kernel below its series’ introducing point (anything on 5.10.y or older) is not affected:

uname -r

Is the OVS kernel datapath in use? The bug is only reachable when the openvswitch module is loaded and handling flows:

lsmod | grep openvswitch

Are conntrack actions in play? OVS conntrack pulls in nf_conntrack; its absence means the ct() action path that drives the overflow is not active:

lsmod | grep nf_conntrack

Can unprivileged users create user namespaces? A non-zero value means a local unprivileged user can obtain CAP_NET_ADMIN in a namespace and reach the OVS netlink API:

sysctl kernel.unprivileged_userns_clone

Where that Debian/Ubuntu knob is absent, check the generic limit instead (0 disables unprivileged user namespaces):

cat /proc/sys/user/max_user_namespaces

Public PoC

The upstream PoC is in manizada/OVSwrap; the researcher’s write-up describes the primitive, and the repository also ships a BPF-based mitigation. Do not run the exploit on a system you are not authorised to test.

Mitigation

The real fix is a patched kernel (the 3f1f75536668 backport). Until one is installed, three interim measures narrow the exposure, in the order the write-up recommends — none is a fix.

Disable the openvswitch module (if you don’t use OVS)

If the host does not use the OVS kernel datapath, the surest interim measure is to stop the openvswitch module from loading at all — the vulnerable code is then unreachable, and unlike the userns knob below this also blocks privileged and container callers. Unload it if it is present but idle:

sudo modprobe -r openvswitch

Then keep it from being (re)loaded, including on-demand autoload; install openvswitch /bin/false is surer than a plain blacklist openvswitch, which only suppresses alias-based autoloading:

echo 'install openvswitch /bin/false' | sudo tee /etc/modprobe.d/ovswrap.conf

Only do this where OVS is genuinely unused — a host that runs Open vSwitch (many virtualization, OVN, and Kubernetes nodes) needs the module and must fall back to the measures below.

Disable unprivileged user namespaces (removes the unprivileged trigger)

On Debian/Ubuntu kernels, turn off unprivileged userns so a non-root local user cannot obtain CAP_NET_ADMIN to reach the OVS netlink API:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Persist it:

echo 'kernel.unprivileged_userns_clone=0' | sudo tee /etc/sysctl.d/99-ovswrap.conf

Where that knob is absent, cap the generic limit with user.max_user_namespaces=0 instead. This closes the unprivileged path only; a caller that already holds CAP_NET_ADMIN (root, or a container granted it) is unaffected, and containerized workloads that rely on unprivileged userns will break.

Apply the PoC’s BPF mitigation (last resort)

The PoC repository ships a BPF program that rejects oversized OVS action sets before they reach the vulnerable path. Treat it as a last resort for hosts that must keep the OVS datapath and unprivileged userns enabled; auditing and loading third-party BPF carries its own risk, so prefer the kernel patch wherever it is available.

Risk notes

• OVS datapath hosts with conntrack: the exposed surface is any host running the OVS kernel datapath with conntrack ct() actions — virtualization hosts, OVN/Kubernetes networking nodes, and SDN gateways are the headline population.
• Unprivileged local escalation: with unprivileged user namespaces enabled (common on desktops and many container hosts), an ordinary local user reaches the bug without any prior privilege — shared and multi-user hosts are directly in scope.
• Recent regression, not universal: kernels below their series' introducing point (notably the entire 5.10 line and older EL kernels) are genuinely not affected — check the window before assuming exposure.
• Backports available: the fix has landed in v7.2-rc4 and the maintained stable lines (see the table), but distro kernels that have not yet adopted a fixed release or an independent cherry-pick remain vulnerable — check the distribution row for your kernel.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References