Mitigating OVSwrap (CVE-2026-64531) on Rocky Linux 9 and 10

cve cve-2026-64531 security kernel rocky linux openvswitch mitigation troubleshooting

Arsalan Zaidi
Customer Support Engineering Lead

Jul 27, 2026

Introduction

OVSwrap is a local privilege escalation (LPE) vulnerability in the Linux kernel's Open vSwitch (OVS) flow action parser. A local unprivileged user can trigger an integer overflow in the OVS nested action length field, corrupt kernel memory, and escalate to root. The vulnerability was introduced by upstream commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check"), which removed a 32 KiB internal action size limit that previously prevented the overflow from reaching exploitable size. The fix is upstream commit 3f1f755366687d051174739fb99f7d560202f60b ("net: openvswitch: reject oversized nested action attrs").

This vulnerability is tracked as CVE-2026-64531.

This article covers Rocky Linux 9 and 10 systems, including RLC Pro and CIQ Linux Kernel LT variants. It describes what the vulnerability affects, how to install the patched kernel or apply a mitigation, and how to confirm the system is protected. Rocky Linux 8, CIQ LTS variants, and CIQ Bridge (CentOS 7) are not affected.

Problem

When a valid OVS CLONE action containing many CT (connection tracking) sub-actions is installed on a datapath, the kernel's ovs_ct_copy_action() expands each CT action from its compact validated form into a larger 164-byte internal representation. If the expanded total exceeds 65,535 bytes, the u16 nla_len field written by add_nested_action_end() wraps to a small value. Subsequent kernel functions that iterate the action list use the wrapped length and resume parsing inside attacker-controlled CT label and timeout fields. This gives the attacker a kernel pointer disclosure, a controlled read primitive, and a controlled 32-bit decrement primitive via dst_release() that zeroes out cred->fsuid/fsgid, granting root.

The underlying u16 nla_len overflow in net/openvswitch/flow_netlink.c has existed since 2013, but it was not exploitable while the old 32 KiB internal action limit kept the expanded container below the 65,536-byte wrap threshold. Commit a1e64addf3ff removed that limit in March 2025, making the overflow reachable.

The exploit requires:

Local code execution
Unprivileged user namespace creation (the common path; any process with CAP_NET_ADMIN over an attacker-controlled network namespace, such as a container, can also trigger the corruption without user namespaces)
OVS and conntrack kernel module support present (the openvswitch module can be auto-loaded)

SELinux does not block the exploit. AppArmor does not block it either, except on distributions that use AppArmor to restrict unprivileged user namespace creation.

The exploit is deterministic. Once the per-kernel-build offsets are derived from System.map/kallsyms and kernel BTF, it runs with the reliability of a logic bug. The researcher's proof-of-concept includes pre-derived offsets for approximately 760 kernel builds across many distributions.

Treat the following systems as affected unless they are running a patched kernel or have the mitigation in place:

Rocky Linux 9 and 10 community releases
RLC Pro 9 and RLC Pro 10
CIQ SIG/Cloud Next 9 and 10
CIQ Linux Kernel LT 6.12 and 6.18

Rocky Linux 8 community releases and all CIQ variants based on Rocky 8 (LTS 8.6, LTS 8.10, FIPS 8.6, FIPS 8.10, RLC Pro 8, SIG/Cloud Next 8) are not affected.

CIQ LTS variants (9.2, 9.4, 9.6) are not affected.

CIQ Bridge (CentOS 7) is not affected.

Status

Patched kernels are available. See the Patched Kernels table below for exact versions.
Recommended action: install the patched kernel via sudo dnf update kernel* and reboot. See Installing the Update below. If you cannot reboot immediately, apply one of the mitigations in the Mitigation section to reduce exposure until the update can be applied. The mitigations are not required on systems already running a patched kernel.
Existing Dirty Frag/Fragnesia mitigations do not cover OVSwrap. The Dirty Frag module block (esp4/esp6/rxrpc) targets a different kernel subsystem. However, if you applied the namespace sysctl (user.max_net_namespaces=0 or user.max_user_namespaces=0), that does block the local unprivileged root path for OVSwrap as well. It does not cover the container/CAP_NET_ADMIN path.
Rocky Linux community releases (9.x, 10.x) will receive patched kernels from RESF. Check Rocky Linux Errata for availability.
Open a support case if you need help assessing exposure or planning mitigation deployment.

Patched Kernels

Variant	Patched Kernel Version	Repository	Released
RLC Pro 9	`kernel-5.14.0-687.29.1+2.1.el9_8_ciq`	`rlc-9`	2026-07-27
CIQ SIG/Cloud Next 9	`kernel-5.14.0-687.29.1+2.1.el9_8_ciq`	`ciq-sigcloud-next-9`	2026-07-27
RLC Pro 10	`kernel-6.12.0-211.37.1+2.1.el10_2_ciq`	`rlc-10`	2026-07-27
CIQ SIG/Cloud Next 10	`kernel-6.12.0-211.37.1+2.1.el10_2_ciq`	`ciq-scn-10`	2026-07-27
CIQ Linux Kernel LT 6.12	`kernel-clk6.12-6.12.97-1.1.el9_clk`	`rlc-9-clk-6.12`	2026-07-27
CIQ Linux Kernel LT 6.18	Pending	`rlc-9-clk-6.18`	Pending

For Rocky Linux community releases, check Rocky Linux Errata for patched kernel availability.

Confirm what is running on a given system with:

uname -r

If your system reports one of the patched versions above (or newer), the fix is in place and the mitigation can be reverted. See Resolution.

Installing the Update

RLC Pro and CIQ SIG/Cloud Next Variants

For RLC Pro 9, RLC Pro 10, and CIQ SIG/Cloud Next 9 and 10, the patched kernel is available from the respective depot repository. No additional repository configuration is required beyond what your variant already uses:

sudo dnf update kernel*
sudo reboot

CIQ Linux Kernel LT 6.12 and 6.18

For CIQ Linux Kernel LT variants, the patched kernel is available from the CLK depot channel:

sudo dnf update kernel*
sudo reboot

Community Edition (RESF)

For Rocky Linux 9.x and 10.x community editions from RESF, patched kernels will be available from the standard BaseOS repository once RESF builds ship. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

Mitigation

Two mitigation options are available. If your hosts do not run Open vSwitch, blacklisting the openvswitch module is the simplest and most complete option. If your hosts run OVS and you cannot stop it, disabling unprivileged user namespaces blocks the local root path (but does not protect against the container escape vector).

Checking for prior exploitation

The OVSwrap proof-of-concept writes a sudoers drop-in file granting the attacking user passwordless root access, modifies the process credentials in memory, and leaves background processes running to keep the network namespace alive. If you suspect a system may have been targeted:

Check for unexpected files in /etc/sudoers.d/:

ls -la /etc/sudoers.d/

Review each file. Any file you did not create or that grants unexpected NOPASSWD access should be investigated and removed.

Check for processes holding private network namespaces owned by unprivileged users:

lsns -t net

Look for network namespaces with no clear purpose. The exploit leaves a keeper process in a private network namespace to prevent the corrupted OVS flow from triggering a crash on namespace teardown.

The credential modification (fsuid/fsgid zeroed) is in-memory only and does not persist across a reboot. If exploitation is confirmed, remove the unauthorized sudoers drop-in, kill any keeper processes, and reboot. Rebooting clears the in-memory corruption and restores normal credential state.

Blacklist the openvswitch module

If your systems do not use Open vSwitch, blocking the openvswitch kernel module is the most targeted and complete mitigation. This prevents the exploit from reaching the vulnerable code path regardless of whether the attacker uses unprivileged namespaces or a container with CAP_NET_ADMIN.

Warning: Blocking openvswitch disables kernel-level OVS datapath support. This breaks OVN, Open vSwitch switch daemons (ovs-vswitchd), and any SDN or virtual networking stack that relies on the kernel OVS module. DPDK-based OVS userspace datapaths do not use the kernel module and are not affected by the vulnerability or this mitigation. Validate the impact on your workload before applying fleet-wide.

Step 1: install the modprobe override.

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

Step 2: clear any resident copy of the module.

The modprobe override blocks future load attempts but has no effect on the module if it is already in memory.

Perform a reboot. This is the preferred path.

sudo reboot

After the reboot, the modprobe override blocks the module from loading.

Unloading without a reboot.

If a reboot is not feasible and the module is currently loaded, stop the OVS daemon and unload it:

sudo systemctl stop openvswitch
sudo rmmod openvswitch

If rmmod fails because the module has active consumers (bridges, flows, or other OVS kernel objects), those must be torn down first. If you cannot tear down the consumers, a reboot is required.

Disable unprivileged user namespaces

The exploit's local root path enters a private user and network namespace to create the OVS datapath. Blocking unprivileged namespace creation stops this path without affecting OVS itself.

Warning: This mitigation only blocks the local unprivileged root path. Any process with CAP_NET_ADMIN over an attacker-controlled network namespace (such as a container) can still trigger the kernel corruption. If your systems run containers with CAP_NET_ADMIN, use the openvswitch module block instead. Disabling unprivileged user namespace creation also breaks rootless container runtimes (rootless Podman, rootless Docker, slirp4netns, pasta), sandboxed browsers (Chromium, Firefox sandbox), and Flatpak applications. Validate the impact on your workload before applying fleet-wide.

If you already applied the Dirty Frag or Fragnesia namespace mitigation and /etc/sysctl.d/dirtyfrag.conf contains user.max_net_namespaces=0, that configuration also blocks the OVSwrap local root path. No additional action is needed for the local unprivileged case. Verify it is still active:

sysctl user.max_net_namespaces

If the output shows user.max_net_namespaces = 0, the local root path is already blocked.

To apply on a system without an existing namespace mitigation:

echo "user.max_net_namespaces=0" | sudo tee /etc/sysctl.d/ovswrap.conf
sudo sysctl --system

Verify:

sysctl user.max_net_namespaces

Output should be user.max_net_namespaces = 0.

To revert after installing a patched kernel:

sudo rm /etc/sysctl.d/ovswrap.conf
sudo sysctl --system

Verification

If using the openvswitch module block

Confirm the module is not loaded:

lsmod | grep openvswitch

No output means the module is not currently loaded.

Confirm the modprobe override is in place:

sudo modprobe -n -v openvswitch

Should print install /bin/false. If it resolves to a .ko path, re-check /etc/modprobe.d/ovswrap.conf and confirm it is present and readable.

If the module still appears in lsmod after applying the mitigation, the running kernel remains exposed. If you rebooted and the module still appears, the override is not catching the early-boot load path: confirm the conf file is present and readable, rebuild the initramfs to include the modprobe config, and reboot again. If you used the no-reboot path, a consumer is still holding the module; re-run ovs-vsctl show to confirm no bridges remain and ensure no other process has the module open before retrying rmmod.

If using the namespace sysctl

Confirm the sysctl is active:

sysctl user.max_net_namespaces

Output should be user.max_net_namespaces = 0.

Resolution

After installing a patched kernel and rebooting, verify the running kernel matches a patched version from the Patched Kernels table:

uname -r

If your system reports one of the patched versions (or newer), the fix is in place and the mitigation can be reverted.

If you applied the openvswitch module block:

sudo rm /etc/modprobe.d/ovswrap.conf
sudo modprobe openvswitch

Confirm the module loaded:

lsmod | grep openvswitch

If you applied the namespace sysctl:

sudo rm /etc/sysctl.d/ovswrap.conf
sudo sysctl --system

Notes

Different vulnerability class from Dirty Frag/Fragnesia. OVSwrap is an integer overflow in the OVS flow action parser, not a page-cache corruption via ESP/xfrm. The affected kernel module is openvswitch, not esp4/esp6/rxrpc. The Dirty Frag module-block mitigation (/etc/modprobe.d/dirtyfrag.conf) does not cover OVSwrap. However, the Dirty Frag namespace sysctl (user.max_net_namespaces=0) does block the local unprivileged root path for OVSwrap.
Container escape vector. Any process with CAP_NET_ADMIN over an attacker-controlled network namespace can trigger the host kernel corruption, potentially enabling container escape. The namespace sysctl does not address this vector. The openvswitch module block is the only complete mitigation short of a patched kernel.
SELinux and AppArmor. SELinux does not block the exploit. AppArmor does not block it either, except on distributions that restrict unprivileged user namespace creation through AppArmor profiles (Rocky Linux does not do this by default).
Public exploit availability. A working proof-of-concept with pre-derived offsets for approximately 760 kernel builds is publicly available. Treat affected systems with local users or untrusted workloads as actively exploitable.
Rocky Linux 8 and CentOS 7 are not affected. The 4.18 kernel (Rocky 8) and 3.10 kernel (CentOS 7) predate the commit that made the overflow exploitable. CIQ LTS variants (9.2, 9.4, 9.6) are also not affected.

Dirty Frag and Fragnesia: prior CIQ kernel local-privilege-escalation advisories referenced in the mitigation guidance above. The namespace sysctl (user.max_net_namespaces=0) shipped for those issues also blocks the OVSwrap local unprivileged root path.

References

Upstream fix commit 3f1f755366687d051174739fb99f7d560202f60b ("net: openvswitch: reject oversized nested action attrs"), Linux kernel.
Regression-introducing commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check"), Linux kernel.
Rocky Linux Errata: https://errata.rockylinux.org/
CVE: CVE-2026-64531.