OVSwrap (CVE-2026-64531) local root exploit: mitigation for CloudLinux 9, 10, and CloudLinux for Ubuntu

Asim Manizada disclosed OVSwrap (CVE-2026-64531) on the oss-security mailing list on July 28, together with a full write-up and a working exploit. It is a local privilege escalation in the Linux kernel’s Open vSwitch module. An unprivileged user on an affected server can become root: no sudo, no capabilities, and nothing an administrator has to do first.

The bug is in the Linux kernel itself, not in anything CloudLinux ships. It reaches the EL9 and EL10 families, which puts RHEL, AlmaLinux, Rocky and CloudLinux in the same position, along with several Debian and Ubuntu releases. This advisory covers the CloudLinux side of it. If you run other distributions next to your CloudLinux fleet, treat them as in scope and follow those vendors’ advisories.

On CloudLinux 9 and CloudLinux 10 there is no patched kernel to install yet. Both track AlmaLinux kernels directly, the fix is expected in the AlmaLinux 9.9 and 10.3 kernel streams or later, and that timing follows Red Hat’s schedule rather than ours. It is the same wait every EL9 and EL10 distribution is in. Until a kernel ships, the mitigation below is the recommended fix.

“Local” here does not mean an employee or a customer you trust. On a shared server, the local user is whoever just got into one of the sites you host through an outdated plugin. OVSwrap is what turns that single-site problem into a whole-server problem.

Affected CloudLinux versions

^† CloudLinux 8 runs its own kernel line, separate from AlmaLinux 8. Our kernel team has finished the source review and confirmed the vulnerable code path is not present, which matches the earlier empirical result that the public exploit does not run against that kernel. This advisory previously listed CloudLinux 8 as under investigation and recommended the mitigation as a precaution. If you applied it there, you can remove it.

A KernelCare livepatch closes the vulnerability without a reboot on every affected version. See Stream 3 for current feed availability.

Am I exposed?

Two things have to be true for a server to be exposed: the kernel is in the affected range, and the openvswitch module is loadable on it. Check both.

1. Check the kernel version

uname -r

The elX_Y suffix is the part that matters:

• CloudLinux 9 is affected from el9_7 onward. el9_6 and earlier are not affected, and need no action.
• CloudLinux 10 is affected from el10_1 onward. el10_0 is not affected.

So a kernel ending .el9_7.x86_64 is in range, and one ending .el9_6.x86_64 is not. On CloudLinux for Ubuntu 22.04 the kernel comes from Canonical and carries no el suffix, so treat it as in range and go to the next check.

2. Check for the module

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

If it prints a path, openvswitch.ko is loadable on that server and an unprivileged user can make the kernel load it on demand. Apply the mitigation below.

If it prints nothing, the module is not present for your running kernel. A later kernel update can bring it back, so run the check again after you update.

Open vSwitch does not need to be configured, running, or in use for any of this. The exploit causes the module to load by itself.

Checking the package is not enough. openvswitch.ko is not always delivered by kernel-modules-extra, so rpm -q kernel-modules-extra can come back empty on a server that is fully exposed. On CloudLinux 10 that package is installed by default. On CloudLinux 9 it often is not, but the module still ships inside the main kernel-modules package. Check for the file, not the package.

Is there a mitigation?

Yes, and it is the recommended action right now on every affected server.

Block the module from loading

echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf

This takes effect immediately, needs no reboot, and touches nothing else on the server.

Use install openvswitch /bin/false rather than blacklist openvswitch. A blacklist only prevents autoloading through /etc/modules-load.d/, udev, and hotplug. It does not block the kernel-side request_module() call that an unprivileged netlink probe triggers, which is exactly the path this exploit uses. The install line replaces the modprobe command for this module with /bin/false, so every load attempt fails, whether it comes from root, from an unprivileged trigger, or from the kernel itself.

If the module is already loaded on a server that does not use it, unload it as well:

lsmod | grep -E '^openvswitch'
modprobe -r openvswitch

Confirm the block is working:

modprobe openvswitch      # should fail
lsmod | grep openvswitch  # should print nothing

Compatibility. Do not apply this on a server that genuinely runs Open vSwitch: OVN and OpenStack Neutron compute or network nodes, some Kubernetes network plugins such as ovn-kubernetes and Antrea, and libvirt or oVirt setups with OVS-backed bridges. On those servers, use the second layer below or wait for the livepatch. On most hosting servers this is safe.

Once a fixed kernel or the livepatch is in place, revert with:

rm /etc/modprobe.d/ovswrap.conf

Second layer: disable unprivileged user namespaces

The exploit reaches CAP_NET_ADMIN by entering a private user and network namespace. Denying unprivileged user namespaces breaks that step regardless of module state. The setting differs by platform.

On CloudLinux 9 and 10:

sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/ovswrap.conf

On CloudLinux for Ubuntu 22.04:

sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' > /etc/sysctl.d/ovswrap.conf

On Ubuntu, note that apparmor_restrict_unprivileged_userns does not mitigate this. We tested it. Use the sysctl above, which removes the namespace outright.

Compatibility. This one is broader than the module block and it breaks things: rootless Docker and Podman, Kubernetes rootless mode, Snap and Flatpak sandboxing, and the Chromium and Firefox sandboxes all need unprivileged user namespaces. Typical hosting workloads do not. cPanel, Plesk and DirectAdmin stacks, the PHP, Node.js, Python and Ruby selectors, and ordinary customer sites are unaffected by this change.

The module block is sufficient on its own. Add this second layer only if you want the extra depth, or if you run Open vSwitch legitimately and cannot block the module.

Update instructions

Stream 1: AlmaLinux kernel (CloudLinux 9 and CloudLinux 10)

Once fixed kernels reach the production repositories, the standard update path applies:

dnf update 'kernel*'
reboot

Until then, apply the mitigation or the KernelCare livepatch.

Stream 2: Ubuntu kernel (CloudLinux for Ubuntu 22.04)

Apply Canonical’s kernel updates as they arrive:

apt update
apt upgrade
reboot

Until then, apply the mitigation or the KernelCare livepatch.

Stream 3: KernelCare livepatch

The livepatch applies the upstream fix to the running kernel, with no reboot and no maintenance window.

Subscribed servers receive it automatically on the next scheduled run. To pull it immediately:

kcarectl --update

Once the livepatch is in place, the module block is no longer needed on that server. See Is there a mitigation? for how to revert it.

How to verify you are patched

For the KernelCare livepatch:

kcarectl --patch-info | grep CVE-2026-64531

Use –patch-info for this. kcarectl –info does not list individual CVEs and will come back empty even on a patched server.

For a kernel update, compare uname -r against the target version in the relevant stream above.

For the mitigation:

modprobe openvswitch      # should fail
lsmod | grep openvswitch  # should print nothing

If you think a server was already exploited

Patching does not undo a compromise that already happened. The public exploit finishes by writing a rule into the sudoers configuration and opening a root shell, so an attacker who succeeded before you patched keeps a way back in.

On any server you have reason to suspect, audit /etc/sudoers and every file under /etc/sudoers.d/ for entries nobody on your team added, then check for unfamiliar accounts and SSH keys.

Why this matters on a shared host

The reason this one matters on a hosting server is that every step after the first is free.

1. A site gets compromised. An outdated plugin or CMS gives an attacker code execution as an unprivileged process, confined to one account.
2. The module loads itself. From that confined process, a single generic-netlink probe makes the kernel load openvswitch.ko. No sudo, no capabilities, no administrator involvement.
3. The attacker gets network admin rights in a private namespace. Entering a private user and network namespace grants CAP_NET_ADMIN inside it, which is enough to install Open vSwitch flows. The capability is never needed on the host itself.
4. The malformed flow escalates to root. The exploit installs a flow that trips the bug and walks the resulting memory access primitives up to a root shell.
5. Tenant boundaries stop applying. Root reaches every other account on that server: files, databases, credentials, and backups.

With the module blocked or the livepatch applied, step 2 fails and the chain stops there. A compromised website stays a compromised website. That is one account to clean up instead of a server to rebuild and a disclosure to write.

Technical details of the bug

Open vSwitch validates a flow’s action list before installing it. Nested actions, in particular the recursive OVS_ACTION_ATTR_CLONE wrapper, get expanded into an internal action stream that the kernel generates itself. Nothing checked that a single generated nested attribute still fits the 16-bit nla_len field, which tops out at 65,535 bytes.

Pack hundreds of small conntrack actions inside a CLONE wrapper and the generated stream runs past that limit. The oversized length is assigned into the 16-bit field and wraps to a small value. Validation passes.

The damage happens later. A subsequent dump or teardown walks a structurally different stream than the one that was validated: it trusts the wrapped length, resumes parsing partway into attacker-controlled bytes, and reads forged action headers planted there as though they were real actions.

From there the chain is short. Fake tunnel SET actions yield a kernel pointer leak and a kernel memory read. Tunnel-destination teardown yields a constrained write, specifically a targeted 32-bit reference-count decrement. The public exploit forks a helper process on the host before entering the namespace, uses that decrement to corrupt the helper’s credentials, writes a sudoers rule, and spawns a root shell.

No race condition is involved. The bug is a mismatch between what the kernel validated and what it parses afterwards.

Reaching it requires x86-64, an Open vSwitch datapath built with conntrack and FTP-helper support, and permission to create unprivileged namespaces.

Why kernel version numbers are a poor guide here

The unsafe assignment is roughly 13 years old. Older kernels carried a 32 KiB cap on the generated action stream that kept it out of reach, and that cap was removed in March 2025. Removing it is what turned a latent bug into an exploitable one.

Upstream, the affected window runs from 6.14 to 7.2-rc3, and the published stable ranges begin at 5.15.180. Distribution kernels carry backports, which scrambles that arithmetic completely: a CloudLinux 9 kernel numbered 5.14 is affected from el9_7 onward, while a CloudLinux 8 kernel numbered 4.18 is not affected at all. The affected list on this page comes from checking each kernel line individually, not from comparing version numbers against the upstream window. If you are assessing other systems, do the same.

References

• oss-security disclosure, Asim Manizada, July 28 2026: openwall.com
• Researcher write-up: heyitsas.im/posts/ovswrap
• Public proof-of-concept: manizada/OVSwrap
• Upstream fix: commit 3f1f75536668, “net: openvswitch: reject oversized nested action attrs”
• CVE record: CVE-2026-64531
• NVD entry: CVE-2026-64531
• CloudLinux status page: OVSwrap incident