In the Linux kernel

CVE-2026-64531, dubbed OVSwrap, is an integer-wraparound bug in the Linux kernel's Open vSwitch (OVS) datapath module. When validating nested flow actions (CT or CLONE wrappers), the kernel stores the generated action stream length in a u16 (nla_len). A prior commit removed the guard that prevented a single nested attribute from exceeding 65,535 bytes. By packing hundreds of small conntrack actions inside a CLONE wrapper, an attacker pushes the generated stream past U16_MAX, causing the length field to wrap to a small value. On subsequent dump or teardown, the parser resumes inside attacker-controlled data and treats forged action headers as legitimate kernel operations — giving full credential overwrite and root. Affected kernels span virtually every maintained stable tree: everything before 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5. This covers the entire EL9/EL10 family, multiple Debian stable releases, and Ubuntu 22.04–26.04 before their respective kernel updates.

The vendor's HIGH / 7.8 rating is accurate and defensible. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) correctly captures that this is a local, low-complexity, low-privilege escalation to full root. One might argue for *upgrading* it given the public weaponized PoC and the fact that many distros auto-load openvswitch on demand, but the local-access prerequisite is a genuine limiting factor for initial access. The score stands.

Why this verdict

• Public weaponized exploit with broad kernel coverage. The PoC is reliable across ~800 kernel builds, self-contained, and requires no pre-existing OVS configuration. This eliminates the usual kernel-exploit friction of version-specific offsets and unreliable heap manipulation.
• Low friction attack chain. The four prerequisites — local shell, unprivileged userns (default on Ubuntu/RHEL 9+), openvswitch module available (default in distro kernels), and CAP_NET_ADMIN in namespace (automatic) — are all met on default installations. The only hard prerequisite is initial local access.
• Role multiplier: OVS is canonically deployed on (a) KVM/OpenStack compute hypervisors where root = access to all guest VM disk images and memory, blast radius = fleet-scale; (b) Kubernetes nodes running OVN-Kubernetes or Antrea where root = access to all pod secrets and potentially cluster control-plane credentials, blast radius = cluster-scale; (c) SDN network infrastructure where root = network control plane compromise. These high-value roles represent a *majority* of intentional OVS deployments (>50% of OVS installs are on hypervisors or k8s nodes by design), establishing a HIGH floor. On workstations or generic servers where OVS is not intentionally deployed, the module is still often available for auto-loading, making them opportunistically vulnerable.
• Local-access prerequisite is genuine friction but not a floor-breaker. The AV:L vector means this is a post-initial-access escalation tool, not a first-stage exploit. However, any compromised container, web app, or stolen SSH key on a hypervisor or k8s node becomes an instant root chain — this is the exact escalation step attackers need after container escape or lateral movement.

Why not higher?

CRITICAL would require either remote exploitability, active in-the-wild exploitation, or a scenario where the bug is directly reachable without prior compromise. OVSwrap requires a local shell first — an attacker cannot exploit this from the internet. The Scope is Unchanged in the CVSS vector, and while practical root access is devastating, the pre-authentication barrier of local access is a real constraint that separates this from CRITICAL-tier vulnerabilities like Zerologon or MOVEit.

Why not lower?

A downgrade to MEDIUM is blocked by the high-value-role floor. OVS is *the* networking datapath for KVM hypervisors and major Kubernetes CNI implementations — root on these hosts is fleet-scale compromise. The public PoC is reliable, self-contained, and works on default configurations. The module auto-loads on most distros, so even hosts not intentionally running OVS are exposed. Any multi-tenant Linux environment with shell access (shared hosting, CI runners, container platforms) is at elevated risk.

1. Blacklist the openvswitch kernel module immediately — Run echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap-cve-2026-64531.conf on all hosts not actively using OVS. This prevents auto-loading and completely blocks the exploit with no reboot required. Deploy within the noisgate mitigation SLA of 30 days; for hypervisors and k8s nodes running OVS, prioritize the kernel patch instead.
2. Restrict unprivileged user namespaces — Set sysctl kernel.unprivileged_userns_clone=0 (Debian/Ubuntu) or apply AppArmor userns restrictions (Ubuntu 24.04+). This breaks the unshare-based namespace trick that gives unprivileged users CAP_NET_ADMIN. Note: this may break some containerized workloads — test in staging first. Deploy within 30 days per noisgate mitigation SLA.
3. Prioritize kernel patching on OVS-active hosts — Hypervisors, Kubernetes nodes, and SDN infrastructure running OVS cannot use the module blacklist without breaking production networking. These hosts MUST be patched to a fixed kernel version. Schedule maintenance windows for these high-value hosts first, within the noisgate remediation SLA of 180 days, but aim for 30 days given the public PoC.
4. Deploy auditd rules for unshare and module loading — Add auditd rules: -a always,exit -F arch=b64 -S unshare -F key=userns and -a always,exit -F arch=b64 -S finit_module -F key=modload. This provides detection coverage while patches roll out. Deploy alongside mitigation controls.

Run this script on each target Linux host as any user (no root needed). Invoke with: bash check_ovswrap.sh. It checks the running kernel version against known-fixed stable releases and whether the openvswitch module is loadable.

#!/bin/bash
# check_ovswrap.sh — CVE-2026-64531 (OVSwrap) vulnerability checker
# Run on target Linux host. No root required.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

KERNEL=$(uname -r)
echo "[*] Running kernel: $KERNEL"

# Extract major.minor.patch from kernel version string
MAJOR=$(echo "$KERNEL" | cut -d. -f1)
MINOR=$(echo "$KERNEL" | cut -d. -f2)
PATCH=$(echo "$KERNEL" | cut -d. -f3 | grep -oE '^[0-9]+')

if [ -z "$MAJOR" ] || [ -z "$MINOR" ] || [ -z "$PATCH" ]; then
  echo "[?] UNKNOWN — could not parse kernel version"
  exit 2
fi

# Check if openvswitch module is available
OVS_AVAIL="no"
if lsmod 2>/dev/null | grep -q openvswitch; then
  OVS_AVAIL="loaded"
elif modprobe --dry-run openvswitch 2>/dev/null; then
  OVS_AVAIL="available"
elif find /lib/modules/"$KERNEL" -name 'openvswitch.ko*' 2>/dev/null | grep -q .; then
  OVS_AVAIL="available"
fi
echo "[*] openvswitch module status: $OVS_AVAIL"

if [ "$OVS_AVAIL" = "no" ]; then
  echo "[+] PATCHED (not vulnerable) — openvswitch module not available on this kernel"
  exit 0
fi

# Check module blacklist
if grep -rqs 'install openvswitch /bin/false\|blacklist openvswitch' /etc/modprobe.d/ 2>/dev/null; then
  echo "[+] PATCHED (mitigated) — openvswitch module is blacklisted via modprobe.d"
  exit 0
fi

# Version comparison: fixed versions by stable branch
# 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5
VULN=0
case "${MAJOR}.${MINOR}" in
  5.15) [ "$PATCH" -lt 212 ] && VULN=1 ;;
  6.1)  [ "$PATCH" -lt 178 ] && VULN=1 ;;
  6.6)  [ "$PATCH" -lt 145 ] && VULN=1 ;;
  6.12) [ "$PATCH" -lt 97 ]  && VULN=1 ;;
  6.18) [ "$PATCH" -lt 40 ]  && VULN=1 ;;
  7.1)  [ "$PATCH" -lt 5 ]   && VULN=1 ;;
  7.*)  VULN=0 ;;  # 7.2+ assumed fixed
  *)
    # Kernels on branches not in the fixed list (e.g. 6.2-6.5, 6.7-6.11, 6.13-6.17)
    # are EOL upstream; assume vulnerable if OVS module is present
    if [ "$MAJOR" -ge 5 ]; then
      echo "[!] Kernel ${MAJOR}.${MINOR} is not a current stable branch — likely vulnerable if unpatched by distro"
      VULN=1
    fi
    ;;
esac

if [ "$VULN" -eq 1 ]; then
  echo "[-] VULNERABLE — kernel $KERNEL is below the fix for CVE-2026-64531 and openvswitch module is $OVS_AVAIL"
  exit 1
else
  echo "[+] PATCHED — kernel $KERNEL is at or above the fixed version for CVE-2026-64531"
  exit 0
fi

Sources

1. oss-security disclosure by Asim Manizada
2. The Hacker News — OVSwrap coverage
3. CloudLinux mitigation guide
4. SecurityOnline — PoC disclosure details
5. Tenable CVE entry
6. CyberPress — technical analysis
7. University of Wisconsin security announcement
8. Red Hat CVE page