Skip to main content
Sign in

CloudLinux Knowledge Base

  1. CloudLinux
  2. CloudLinux OS
  3. CloudLinux Kernels

Kernel Local Privilege Escalation CVE-2026-64531 (OVSwrap, Open vSwitch) — Affected Status and Fix

Jeffrey Encarnacion
  • Updated

Issue

CVE-2026-64531 ("OVSwrap") is a local privilege escalation vulnerability in the Linux kernel Open vSwitch datapath module (openvswitch.ko). An unprivileged local user can make the kernel auto-load the module and then escalate to root. The flaw is local-only, with no remote attack vector. It was publicly disclosed on 28/07/26 with a working proof-of-concept.

An empty lsmod | grep openvswitch does not mean a server is protected: the module ships on disk with the kernel and a local user can trigger it to load on demand.

Environment

  • CloudLinux OS 9 (el9_7 and later) and CloudLinux OS 10 (el10_1 and later) — affected
  • AlmaLinux 9 and 10, and other Enterprise Linux 9 and 10 systems — affected by the same kernel code
  • CloudLinux OS 7, 7h, and 8 — not affected (kernel outside the vulnerable range); CloudLinux OS 8 confirmation is still in progress
  • Servers with the kernel-modules-extra package installed (it ships openvswitch.ko)
  • Multi-user or shared hosting environments with untrusted local users

Solution

Current status, per CloudLinux version and per KernelCare feed, is published and kept up to date on the status page: 
https://cloudlinux.statuspage.io/incidents/byy8q48qhx01

Follow the steps below and use the status page to confirm what is available for your OS at the moment.

1. Check whether the module is present:

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

If a path is printed, the module is present and the server is exposed until it is patched or blocked.

2. Apply the KernelCare live patch where one is available. Live patches for Enterprise Linux 9 kernels (CloudLinux 9, AlmaLinux 9, RHEL 9, Rocky Linux 9, Oracle Linux 9) were released on 30/07/26; Enterprise Linux 10 coverage is in preparation. A KernelCare license obtained through Imunify360 covers this as well:

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

If the patch is installed but the CVE is not listed, check the build date instead — a build from 29/07/26 or later includes the fix:

 
kcarectl --info | grep kpatch-build-time

3. If no live patch is available yet for your kernel, block the module. This takes effect immediately and requires no reboot:

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

Verify with read-only checks:

modprobe --showconfig | grep openvswitch   # shows: install openvswitch /bin/false
lsmod | grep openvswitch                   # prints nothing

If you prefer an active check, modprobe openvswitch fails with could not insert 'openvswitch': Invalid argument. That error confirms the block is working.

4. If lsmod shows the module already loaded, unload it:

modprobe -r openvswitch

The rule blocks future loads only; it does not unload a module already in memory. No reboot is required to unload it.

Notes on the mitigation

  • The rule is not tied to a kernel version, so it persists across kernel updates and reboots. It can stay in place after a fixed kernel or live patch is installed, and it is reversible with rm /etc/modprobe.d/ovswrap.conf
  • openvswitch.ko stays on disk, and modinfo openvswitch still returns output after the mitigation is applied. This is expected — the rule stops the module from loading; it does not delete the file
  • Do not apply the mitigation on servers that legitimately use Open vSwitch: OpenStack or OVN and Neutron nodes, Kubernetes network plugins such as ovn-kubernetes and Antrea, libvirt or oVirt hosts with Open vSwitch bridges, and SolusVM 2 KVM nodes. Use the KernelCare live patch on those servers instead. To confirm Open vSwitch is not in use, check that all of the following return nothing:
lsmod | grep -w openvswitch
rpm -qa | grep -i openvswitch
ip link show ovs-system 2>/dev/null
systemctl is-active openvswitch ovs-vswitchd 2>/dev/null
  • CageFS does not block this attack. It isolates users at the filesystem level, but does not restrict the netlink call that triggers the module load, so the mitigation or the live patch is still required

Cause

The Open vSwitch datapath does not bound the size of nested action attributes. An oversized nested CT/CLONE action makes the 16-bit nla_len length field wrap to a small value, so the parser resumes inside attacker-controlled data and treats forged action headers as legitimate operations. That yields read and write primitives sufficient to escalate to root. The flaw was fixed upstream by commit 3f1f75536668 ("net: openvswitch: reject oversized nested action attrs"), first shipped in stable releases 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5.

Useful Links

Comments

0 comments

Please sign in to leave a comment.

Related articles