OVSwrap lets local users gain root

The Linux kernel flaw now being called OVSwrap is a local privilege-escalation bug, not a remote break-in. CVE-2026-64531 affects the Open vSwitch datapath in the kernel and can let a local, unprivileged user reach root on affected systems, according to the Red Hat CVE entry and vendor advisories. (bugzilla.redhat.com) Public disclosure began on July 27, and CloudLinux said a working proof of concept was public by July 28. ### Where in the kernel does the bug sit? Red Hat’s CVE description places the flaw in `net/openvswitch`, the Linux kernel code that handles Open vSwitch flow actions. The bug is described as “reject oversized nested action attrs,” and stems from generated flow actions stored as netlink attributes whose `nla_len` field is 16 bits wide. (ubuntu.com) The Linux kernel’s own Open vSwitch documentation describes that subsystem as a kernel module used for flow-level packet processing under userspace control. That matters because the vulnerable code is in the kernel datapath, not only in a separate userspace package. (bugzilla.redhat.com) ### How does a local user get from this bug to root? CloudLinux said an unprivileged local user can cause the kernel to auto-load `openvswitch.ko` and then exploit the flaw to escalate privileges. Its advisory says the issue is local-only, with no remote attack vector, but added that a system is not safe merely because `lsmod` does not show the module already loaded. (bugzilla.redhat.com) Red Hat’s CVE text says a generated nested action can exceed `U16_MAX`, be closed with a truncated length, and later be parsed as a different structure than the one originally validated. (kernel.org) That mismatch is the condition behind the memory corruption path described in the CVE record and downstream advisories. ### Why are vendors warning even if Open vSwitch is not visibly running? CloudLinux said the module can be present on disk as part of normal kernel packaging and loaded on demand by a local user. Its guidance says that if `/lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko*` exists, the server is exposed until it is patched or the module is blocked. (cloudlinux.zendesk.com) That warning lines up with vendor patch tracking elsewhere. Debian’s security tracker lists CVE-2026-64531 with fixed-package information, and Ubuntu’s security notices page shows kernel advisories are being issued in the normal notice stream for supported releases. (bugzilla.redhat.com) ### Which systems are known to be affected? CloudLinux said CloudLinux OS 9 and 10 are affected, along with AlmaLinux 9 and 10 and other Enterprise Linux 9 and 10 systems using the same kernel code, while CloudLinux OS 7 and 8 were outside the vulnerable range or still under confirmation at the time of its notice. (cloudlinux.zendesk.com) Third-party tracking pages tied to the CVE show fixes being backported across multiple stable-kernel lines rather than one single upstream version jump. Tenable’s CVE page links stable-kernel fix commits and says the CVE was published on July 27 and updated on August 1. (security-tracker.debian.org) ### What are administrators being told to do right now? CloudLinux said Enterprise Linux 9 live patches were released on July 30 through KernelCare, while Enterprise Linux 10 coverage was still being prepared. Where no live patch is available, it recommends blocking module loads immediately with a modprobe rule and unloading the module if it is already resident. (cloudlinux.zendesk.com) Ubuntu says security fixes are tracked through Ubuntu Security Notices, and Debian lists fixed source packages in its security tracker. The next step for administrators is to check the exact running kernel, confirm whether the Open vSwitch module is present, and apply the vendor kernel update or live patch published for that distribution. (tenable.com) (ubuntu.com) (cloudlinux.zendesk.com)