The vulnerability is rated 7.8 High by the Linux kernel CNA and Red Hat, with a local, low-complexity, low-privilege attack vector capable of producing high confidentiality, integrity, and availability impact. (NVD)
CVE-2026-64531 is a Linux kernel vulnerability in the Open vSwitch datapath that can allow an ordinary local user to escalate privileges to root on affected systems. The vulnerability is also known as OVSwrap.
At the center of the flaw is a deceptively small data-type boundary. Open vSwitch represents generated flow actions as Netlink attributes. Each attribute contains a 16-bit nla_len field, meaning an individual attribute cannot describe more than 65,535 bytes. The complete generated action stream may legitimately grow beyond that boundary, but every individual nested action still has to fit inside the 16-bit field.
Before the fix, the Linux Open vSwitch implementation failed to enforce that second rule. When a generated nested action exceeded 65,535 bytes, its real length was truncated when stored in nla_len. Later code then walked a different logical action stream from the one originally constructed and validated.
That parsing discrepancy was not limited to a clean rejection or a denial of service. Public research demonstrated that attacker-controlled data inside the oversized action could be interpreted as independent Open vSwitch actions. The published exploit chained the resulting behavior into kernel pointer disclosure, kernel-memory reads, a constrained modification primitive, host credential corruption, and root-level code execution. (NVD)
CVE-2026-64531 was published on July 27, 2026. The Linux kernel CNA assigned it a CVSS 3.1 score of 7.8 High, using the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The public technical disclosure and working proof of concept followed on July 28 after coordinated disclosure with Linux and Open vSwitch maintainers. (NVD)
CVE-2026-64531 at a Glance
| Feld | Einzelheiten |
|---|---|
| CVE-ID | CVE-2026-64531 |
| Common name | OVSwrap |
| Betroffene Komponente | Linux kernel Open vSwitch datapath |
| Primary source file | net/openvswitch/flow_netlink.c |
| Klasse der Anfälligkeit | Nested Netlink attribute length truncation and inconsistent structural parsing |
| Red Hat CWE mapping | CWE-130, Improper Handling of Length Parameter Inconsistency |
| CVSS 3.1 | 7.8 High |
| Angriffsvektor | Local |
| Required initial privileges | Niedrig |
| User interaction | Keine |
| Demonstrated impact | Kernel information disclosure, memory access primitives, credential corruption, root escalation |
| Public exploit | Ja |
| Upstream fix | Reject generated nested attributes larger than U16_MAX and safely unwind partially constructed actions |
| Main temporary mitigation | Block the openvswitch kernel module when it is not required |
| Preferred remediation | Install a vendor-fixed kernel and verify that the fixed kernel is running |
The Linux CVE record describes the flaw as an oversized nested action container being closed with a truncated nla_len. It notes that later flow dumping or teardown can walk a structurally different stream and interpret bytes following an oversized CLONE or CT action as independent actions. Red Hat classifies the weakness as inconsistent length handling that can enable memory disclosure or local privilege escalation. (NVD)
Understanding the Open vSwitch Kernel Datapath
Open vSwitch is a programmable software switch used in virtualization, cloud networking, software-defined networking, container platforms, and network-isolation systems.
On Linux, a common Open vSwitch deployment divides responsibilities between userspace and the kernel. The userspace process determines which flows should be installed, while the kernel datapath performs packet matching and executes associated actions at forwarding speed.
Each datapath contains a flow table. A flow associates a packet key with one or more actions, such as:
- forwarding a packet to another virtual port;
- changing packet or tunnel metadata;
- applying connection tracking;
- cloning a packet and executing another action list;
- sampling traffic;
- selecting actions according to packet length.
The flow keys and action lists are communicated through Generic Netlink. Linux kernel documentation describes the Open vSwitch module as providing userspace-controlled flow-level packet processing, with userspace populating flow tables that map packet keys to action sets. (Linux Kernel Archives)
Netlink attributes are structured records containing a type and a length. The relevant header can be represented as:
struct nlattr {
__u16 nla_len;
__u16 nla_type;
};
Die nla_len field includes the attribute header itself. Because it is an unsigned 16-bit value, its maximum representable value is 65,535. Linux Netlink documentation explicitly identifies nla_len as a __u16 field and explains that the length includes the header but excludes alignment padding. (Linux Kernel Documentation)
Nesting complicates this representation. A parent action such as CLONE can contain a complete child action list. The parent’s nla_len must cover its own header and every recursively contained child. No matter how large the surrounding allocation may be, that individual nested container still has to fit into 16 bits.
The Root Cause of CVE-2026-64531
The root cause is not simply that Open vSwitch allowed a large action stream. The complete action stream being larger than 64 KiB is valid.
The actual error was allowing an individual generated nested attribute to exceed what its 16-bit length field could represent.
When Open vSwitch receives an action list from userspace, it validates the input and converts some actions into an internal representation. That conversion can make the generated action much larger than the userspace input.
Connection-tracking actions are especially important because a compact userspace action can be expanded into a much larger internal ovs_conntrack_info structure. The public analysis measured this generated representation at 164 bytes on the tested x86-64 systems. Hundreds of CT actions nested inside a CLONE action could therefore push the real CLONE length beyond 65,535 bytes. (CIQ Knowledge Base)
Before the vulnerability became reachable, the generated action stream was subject to an older 32 KiB limit. That limit was removed by commit a1e64addf3ff, titled “net: openvswitch: remove misbehaving actions length check.”
The removal itself addressed a legitimate problem: transformations between userspace and internal action representations could cause valid action lists to grow unpredictably, making a fixed total-stream limit unreliable. However, the old cap had also provided an accidental safety boundary. It prevented any nested action from becoming large enough to overflow a 16-bit attribute length.
Once the total-stream cap was removed in March 2025 and the change was backported to several stable branches, the older missing check on individual nested attributes became reachable. The unsafe assignment had existed for years, but the previous size limit had kept it below the exploitation threshold. (Openwall)
Conceptually, the vulnerable logic behaved like this:
real_length = generated_actions_end - nested_action_start;
nested_header->length = real_length;
The first value could be wider than 16 bits. The destination field could not.
A value such as 65,612 therefore did not remain 65,612 when stored in nla_len. It wrapped modulo 65,536 and became 76.
The underlying buffer still contained all 65,612 bytes. Only the recorded nested length had changed.
That distinction is fundamental to understanding CVE-2026-64531. The overflow did not necessarily cause the buffer allocation itself to fail. It caused later code to disagree about where the nested object ended.
Why the Truncated Length Changes the Action Stream
Open vSwitch consumers use each action’s stored nla_len to calculate the location of the next action.
Consider a generated CLONE action whose real boundaries are:
CLONE starts at byte 0
CLONE really ends after byte 65,612
After truncation, the header claims:
CLONE starts at byte 0
CLONE ends after byte 76
A later iterator trusts the stored value, advances 76 bytes, and assumes it has reached the next top-level action.
It has not.
Byte 76 remains inside the first generated connection-tracking object. The parser therefore begins treating internal CLONE payload bytes as though they were new Open vSwitch action headers.
The stream that was validated can be visualized as:
[CLONE
[CT]
[CT]
[CT]
...
]
The stream later observed by the vulnerable parser can instead resemble:
[short CLONE] [attacker-shaped bytes interpreted as action] [more data]
The generated CT structures contain fields influenced by userspace, including connection-tracking labels and timeout names. The researcher used those controlled regions to place values that looked valid when interpreted as Open vSwitch action headers and payloads.
The result was deterministic re-entry into attacker-influenced bytes rather than an unpredictable jump into unrelated memory. This characteristic made the flaw considerably more reliable than many conventional heap-corruption vulnerabilities. (Openwall)
CVE-2026-64531 Attack Chain
The demonstrated attack chain can be summarized as follows:
Ordinary local user
|
v
Create a private user and network namespace
|
v
Gain CAP_NET_ADMIN inside that namespace
|
v
Reach the Open vSwitch Generic Netlink interface
|
v
Cause the openvswitch module to load when available
|
v
Submit a valid nested CLONE action containing many CT actions
|
v
Kernel expands the CT actions into a larger internal representation
|
v
Generated CLONE exceeds 65,535 bytes
|
v
Real length is truncated in the 16-bit nla_len field
|
v
Later dump or teardown resumes parsing inside the CLONE payload
|
v
Attacker-controlled bytes are interpreted as independent OVS actions
|
v
Kernel information disclosure and memory-manipulation primitives
|
v
Host credential corruption
|
v
Root-level file modification and root execution
The original disclosure states that an unprivileged user can create a user and network namespace, obtain CAP_NET_ADMIN within that namespace, and interact with the Open vSwitch flow interface. It also explains that resolving the relevant Generic Netlink family can automatically load the Open vSwitch module if the module is installed and loadable. (Hey, it’s Asim)
This means the attack does not necessarily require:
- a running
ovs-vswitchd; - an existing OVS bridge;
- previous Open vSwitch configuration;
CAP_NET_ADMINin the host’s initial namespace;- the module to have already been loaded;
- a privileged container.
Those conditions materially expand the practical attack surface beyond systems whose administrators consciously operate Open vSwitch.
How the Public Exploit Reaches Root
The exact exploit implementation is not required for safe exposure assessment, and running it on a production server is not an appropriate validation technique. However, understanding its stages explains why CVE-2026-64531 deserves urgent remediation.
Kernel pointer disclosure
The exploit places a forged action at the position where parsing resumes after the wrapped CLONE length.
One technique uses a fake action whose declared size causes a later flow dump to include surrounding generated CT data. Some of that generated data can contain a real kernel pointer associated with the FTP conntrack helper.
When the malformed flow is dumped back to userspace, the pointer becomes observable.
Kernel-memory reading
The exploit then uses a forged tunnel-related SET action. Its attacker-controlled payload is interpreted as containing a tunnel destination pointer.
During flow serialization, Open vSwitch follows that pointer and reads fields from the presumed tunnel metadata. By adjusting the forged pointer relative to known structure offsets, the exploit can recover selected kernel bytes.
This provides a mechanism for identifying the randomized kernel base and locating other kernel objects.
Constrained memory modification
During action teardown, Open vSwitch releases resources associated with tunnel destinations. The public exploit uses a forged pointer so that a reference-count decrement lands on a selected target word.
This is not a conventional arbitrary write. It is a constrained decrement operation. Nevertheless, repeated decrements can modify credential fields or other security-sensitive values.
Credential corruption and root-level action
The published exploit uses the read capability to locate a host process and its credentials. It then repeatedly applies the decrement primitive to change relevant credential fields.
Once the chosen host process has effective filesystem credentials suitable for privileged file access, it writes a sudoers rule and obtains root execution.
The researcher reported that the public x86-64 proof of concept contained precomputed records for approximately 800 kernel builds. Those records account for build-specific structure layouts and symbol offsets that would otherwise need to be derived from kernel debugging data, BTF, System.map, or similar sources. (Openwall)
This public availability sharply reduces the work required to test or weaponize affected systems. It does not prove that every affected architecture and distribution is immediately exploitable by the published implementation, but it removes much of the barrier for a broad collection of common x86-64 kernels.
CVSS and Practical Severity
The assigned CVSS score is 7.8 High:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
The vector reflects several important facts:
- exploitation begins locally rather than over the network;
- attack complexity is considered low;
- the attacker requires only low privileges;
- no user interaction is required;
- successful exploitation can have high confidentiality impact;
- successful exploitation can have high integrity impact;
- successful exploitation can have high availability impact.
The “Local” attack vector should not be interpreted as low operational importance. Local code execution is already available to many threat actors through compromised web applications, malicious dependencies, CI workloads, shared hosting accounts, developer environments, SSH accounts, restricted service users, and containerized jobs.
In such environments, local privilege escalation frequently represents the step that converts an application-level compromise into full host control.
Red Hat’s description states that the truncated length can be used by a local attacker to alter kernel memory, potentially causing sensitive-information disclosure or local privilege escalation. (Red Hat Customer Portal)
Affected Upstream Linux Kernel Versions
The CVE record and researcher’s analysis identify the following upstream stable ranges:
| Kernel series | Affected upstream releases | First fixed upstream release |
|---|---|---|
| 5.15.y | 5.15.180–5.15.211 | 5.15.212 |
| 6.1.y | 6.1.132–6.1.177 | 6.1.178 |
| 6.6.y | 6.6.84–6.6.144 | 6.6.145 |
| 6.12.y | 6.12.20–6.12.96 | 6.12.97 |
| 6.13.y | 6.13.8–6.13.12 | Branch is EOL |
| 6.14.y–6.17.y | All upstream releases in those branches | Branches are EOL |
| 6.18.y | 6.18.0–6.18.39 | 6.18.40 |
| 6.19.y | All upstream releases | Branch is EOL |
| 7.0.y | All upstream releases | Branch is EOL |
| 7.1.y | 7.1.0–7.1.4 | 7.1.5 |
The Linux CVE record also lists fixed versions in the maintained series, including 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, and 7.1.5. (NVD)
These ranges apply to upstream kernels. They are not a reliable replacement for distribution-specific advisories.
A distribution may:
- backport the enabling commit to an older-looking kernel;
- backport the security fix without changing the major upstream version;
- retain the old action-size cap;
- ship different kernel flavours with different patch histories;
- package Open vSwitch as built-in functionality, a loadable module, or a separate module package;
- disable or restrict unprivileged user namespaces;
- provide a live patch independently of the installed package version.
For example, the researcher found that some RHEL-derived 5.14 kernels had received the enabling change even though an upstream 5.14 version would appear older than the affected mainline range. Conversely, some vendor kernels retained the earlier cap and were not exposed in the same way. (Hey, it’s Asim)
Red Hat also warns that version-only scanners can produce incorrect conclusions when vendors backport security fixes into older package versions. The vendor’s package status and errata should therefore be treated as authoritative for vendor kernels. (Red Hat Customer Portal)
Current Debian Status Example
Debian’s tracker illustrates why administrators should use distribution package data instead of relying exclusively on uname -r.
At the time of verification on August 6, 2026, Debian listed:
| Debian release | Package status |
|---|---|
| Bullseye | Not affected by the vulnerable code path |
| Bookworm base package 6.1.176-1 | Verwundbar |
| Bookworm security package 6.1.180-1 | Fixed |
| Trixie base package 6.12.94-1 | Verwundbar |
| Trixie security package 6.12.100-1 | Fixed |
| Forky package 7.1.3-1 | Verwundbar |
| Sid package 7.1.6-1 | Fixed |
Debian’s tracker identifies 6.1.180-1 as the fixed Bookworm version and 6.12.100-1 as the fixed Trixie version. These distribution versions differ from the first upstream fixed versions because Debian applied and packaged its own security updates. (Debian Security Tracker)
Administrators should recheck the relevant vendor tracker at deployment time because package status can change after publication.
Exploitation Preconditions
CVE-2026-64531 is broad, but it is not universally exploitable under every Linux configuration.
A practical exposure assessment needs to evaluate several independent conditions.
An affected kernel must be running
The installed kernel package is not necessarily the kernel currently active in memory. A system may have downloaded a fixed kernel but still be running the vulnerable one because it has not rebooted.
Always distinguish among:
- kernel packages available in repositories;
- kernel packages installed on disk;
- the kernel selected by the bootloader;
- the kernel currently running;
- a live patch applied to the currently running kernel.
The Open vSwitch kernel code must be reachable
The module may be:
- built into the kernel;
- present as a loadable module;
- installed in a separate package;
- absent from the host;
- blocked through module policy;
- already loaded;
- loadable automatically through module aliases.
Checking only lsmod is insufficient. A module that is not loaded at the time of inspection may still be present and automatically loadable when the relevant Generic Netlink family is requested.
The attacker needs control over a network namespace
The vulnerable flow-management operation requires CAP_NET_ADMIN over an attacker-controlled network namespace.
An ordinary user may obtain that capability inside a newly created namespace when unprivileged user namespaces are enabled. Alternatively, a container or network-management process may already possess the necessary namespace-local capability.
The public PoC has additional requirements
The released proof of concept relies on more specific components, including Open vSwitch conntrack support, the FTP conntrack helper, a supported x86-64 kernel build or sufficient symbol information, and a final path involving sudo.
Those are requirements of the published exploit implementation, not necessarily fundamental limits of the underlying parsing vulnerability. (Openwall)
Why “We Do Not Use Open vSwitch” Is Not Enough
A common but unsafe assessment is:
We do not operate an Open vSwitch bridge, so this CVE does not affect us.
The vulnerable code resides in the Linux kernel module rather than exclusively in the ovs-vswitchd userspace service.
On a system where the module is available, an unprivileged process may create its own user and network namespaces and interact with the OVS Generic Netlink families. Resolving those families can trigger module autoloading through registered aliases.
As a result, exposure may exist even when:
systemctl status openvswitch
shows no running service and:
lsmod | grep openvswitch
returns no output.
The more useful question is not merely whether the organization actively uses OVS. The useful questions are:
- Is vulnerable OVS kernel code available to the running kernel?
- Can an unprivileged process reach that code?
- Does the running kernel contain the fix?
- Can the module be safely blocked when it is not required?
The original disclosure tested numerous mainstream distributions in configurations where an ordinary local user could reach the flaw. These included tested versions or tracks of Debian, Ubuntu, Fedora, Amazon Linux, AlmaLinux, Rocky Linux, Arch Linux, Alpine, Kali, NixOS, openSUSE, Linux Mint, Pop!_OS, and others. Exact exposure remained dependent on kernel build, package set, namespace policy, and module availability. (Openwall)
Safe Validation for CVE-2026-64531
A production-safe CVE-2026-64531 validation process should establish exposure through configuration, package, kernel, and source evidence.
It should not attempt to prove exposure by running the public root exploit against a production host.
A successful exploit modifies kernel state and may modify privileged files. Even an unsuccessful attempt can crash the kernel, corrupt memory, alter credentials, or destabilize networking. Public exploit success is also build-dependent, so failure does not prove safety.
Step 1: Record the running kernel and operating system
uname -a
uname -r
cat /etc/os-release
Preserve the exact output in the assessment record.
Do not shorten the kernel release string. Vendor kernels frequently encode important flavour, build, and update information after the upstream version.
Example evidence fields should include:
Hostname:
Distribution:
Distribution release:
Running kernel:
Architecture:
Boot time:
Last kernel package update:
Reboot required:
Step 2: Check whether the Open vSwitch module exists
Verwenden Sie modinfo without loading the module:
modinfo openvswitch 2>/dev/null
Check the running kernel’s module directory:
find "/lib/modules/$(uname -r)" \
-type f \
\( -name 'openvswitch.ko' -o \
-name 'openvswitch.ko.xz' -o \
-name 'openvswitch.ko.zst' -o \
-name 'openvswitch.ko.gz' \) \
-print 2>/dev/null
A returned path means the module is available on disk. It does not establish that the kernel is vulnerable, but it means “OVS is not currently loaded” cannot be used as a mitigation argument.
Step 3: Check whether Open vSwitch is built into the kernel
Where the running kernel configuration is available:
grep '^CONFIG_OPENVSWITCH=' "/boot/config-$(uname -r)" 2>/dev/null
Interpret common results as follows:
CONFIG_OPENVSWITCH=y Built into the kernel
CONFIG_OPENVSWITCH=m Available as a module
# CONFIG_OPENVSWITCH is not set Not enabled in that kernel configuration
Some distributions expose the running configuration through /proc/config.gz:
zgrep '^CONFIG_OPENVSWITCH=' /proc/config.gz 2>/dev/null
A built-in Open vSwitch implementation cannot be mitigated by blacklisting a loadable module. In that situation, patching the kernel or restricting the reachability conditions becomes essential.
Step 4: Check current module state
lsmod | grep -E '^openvswitch\b'
Review kernel messages:
journalctl -k --no-pager | grep -i openvswitch
or:
dmesg | grep -i openvswitch
These checks can reveal current or previous loading activity. They do not establish that an unloaded module is unreachable.
Step 5: Review unprivileged user namespace policy
A useful starting point is:
sysctl kernel.unprivileged_userns_clone 2>/dev/null
sysctl user.max_user_namespaces 2>/dev/null
Not every distribution uses the same control, and a value that appears restrictive may interact with distribution-specific AppArmor, SELinux, container, or sandbox policies.
A non-destructive capability check can be performed in an approved test environment:
unshare -Urn true
A successful command indicates that the current user can create a private user and network namespace. It does not trigger the Open vSwitch vulnerability by itself.
Do not change namespace controls merely to test exploitability on a production host.
Step 6: Check vendor CVE and package status
On Debian or Ubuntu-family systems, capture the installed kernel packages:
dpkg-query -W \
-f='${binary:Package}\t${Version}\t${db:Status-Abbrev}\n' \
'linux-image*' 2>/dev/null
Check the package corresponding to the running kernel:
dpkg-query -W "linux-image-$(uname -r)" 2>/dev/null
On RPM-family systems:
rpm -q kernel
rpm -q "kernel-core-$(uname -r)" 2>/dev/null
Where supported, query security-update metadata:
dnf updateinfo info --cves CVE-2026-64531
Package-manager output should be correlated with the vendor’s CVE page or errata. Absence from local metadata may mean that repository metadata is outdated, the vendor uses a different advisory mapping, the installed system is unsupported, or the relevant fix is still being prepared.
Step 7: Determine whether a fixed kernel is installed but not running
On Debian-family systems:
ls -1 /boot/vmlinuz-* 2>/dev/null
uname -r
On RPM-family systems:
rpm -q kernel-core --last
uname -r
A newer fixed kernel on disk does not protect the running kernel until the host boots into it, unless an independently verified live patch has been applied.
Step 8: Validate custom kernel source
For internally built kernels, examine the exact source tree used for the running build:
git log --oneline --all -- net/openvswitch/flow_netlink.c |
grep -F 'reject oversized nested action attrs'
The relevant upstream fix has the title:
net: openvswitch: reject oversized nested action attrs
Source review should confirm that nested action completion:
- calculates the real attribute length using a sufficiently wide type;
- rejects lengths greater than
U16_MAX; - propagates the error through callers;
- correctly releases resources from partially constructed recursive actions;
- unwinds tunnel destination ownership safely.
The fix is more than a one-line bounds check. The CVE record emphasizes the need to free resources in reverse construction order for recursive SAMPLE, CLONE, DEC_TTL, and CHECK_PKT_LEN builders and to handle SET/TUNNEL ownership correctly. (NVD)
For vendor kernels, the exact upstream commit hash may not appear because the fix can be rebased or backported. Vendor advisory status is usually stronger evidence than a raw commit-hash search.
Step 9: Verify the active remediation
After installing an updated kernel:
uname -r
Compare the output with the fixed package identified by the vendor.
Also record:
uptime -s
The boot time helps demonstrate that the system rebooted after installation.
For an approved live-patching product, use the vendor-specific command to confirm that CVE-2026-64531 is included in the patch currently applied to memory. Do not assume that installation of a live-patch agent means every supported CVE has been patched.
Step 10: Avoid production exploit execution
The public OVSwrap exploit should be restricted to:
- an isolated laboratory;
- a disposable virtual machine;
- a snapshot-backed test environment;
- a matching test kernel;
- an explicitly authorized security assessment;
- a network environment with no sensitive credentials;
- a host whose crash or corruption has no business impact.
Production validation should rely on evidence that is safer and generally more reliable:
Running kernel identity
+ vendor advisory
+ installed package version
+ module availability
+ namespace reachability
+ mitigation state
+ reboot or live-patch evidence
Recommended Remediation
Install a vendor-fixed kernel
The preferred remediation is to install a kernel package containing the vendor’s backport of the upstream fix and then reboot into that kernel.
Do not rely solely on comparison with the first upstream fixed version. Enterprise distributions may fix the flaw in an older-looking kernel release.
After rebooting, collect:
uname -r
cat /etc/os-release
and the relevant package-manager evidence.
Block the Open vSwitch module when OVS is not needed
When Open vSwitch is not used and is built as a module, a temporary module policy can remove the vulnerable path.
A commonly recommended rule is:
sudo sh -c \
"printf '%s\n' 'install openvswitch /bin/false' \
> /etc/modprobe.d/ovswrap.conf"
This causes future attempts to load openvswitch über modprobe to execute /bin/false instead.
Some administrators also add:
sudo sh -c \
"printf '%s\n' 'blacklist openvswitch' \
>> /etc/modprobe.d/ovswrap.conf"
Die install rule is generally the stronger control against ordinary alias-driven module loading.
Before unloading a currently loaded module, determine whether OVS is in active use:
lsmod | grep -E '^openvswitch\b'
command -v ovs-vsctl >/dev/null &&
sudo ovs-vsctl show
Unloading a module that supports production networking may disrupt virtual switches, virtual machines, containers, overlays, OpenStack networking, OVN, Kubernetes networking, or other datapath consumers.
Where it is confirmed safe:
sudo modprobe -r openvswitch
If the module is embedded in the initial RAM filesystem, rebuild the initramfs according to the distribution.
Debian-family example:
sudo update-initramfs -u
RPM-family example:
sudo dracut -f
Verify the policy:
modprobe -n -v openvswitch
Expected output should show that /bin/false would be invoked.
CloudLinux and Rocky Linux guidance published for the vulnerability also recommends blocking the module when OVS is unnecessary. (CloudLinux Blog)
Disable unprivileged user namespaces only as a secondary mitigation
Disabling unprivileged user namespaces can remove the simplest route available to an ordinary local user.
Depending on the distribution, a temporary setting may resemble:
sudo sysctl -w kernel.unprivileged_userns_clone=0
A persistent setting may be placed in an approved sysctl configuration file and then loaded through the distribution’s normal process.
This mitigation has substantial compatibility implications. Unprivileged user namespaces are used by rootless container systems, browser sandboxes, Flatpak, Bubblewrap and other isolation mechanisms.
It is also incomplete. It does not necessarily protect against:
- containers already granted suitable
CAP_NET_ADMIN; - services already operating in controlled network namespaces;
- privileged network-management processes;
- another compromise that provides the required capability.
The original disclosure therefore describes namespace restriction as a temporary measure rather than a substitute for patching. (Openwall)
Remove unnecessary CAP_NET_ADMIN grants
Review container, CI and service configurations for unnecessary network-administration capabilities.
Docker-style configurations should not grant:
CAP_NET_ADMIN
unless the workload has a documented need.
In Kubernetes, review securityContext.capabilities.add entries and privileged workloads. Also review host-level agents, CNI components, network appliances and troubleshooting containers that may intentionally possess networking capabilities.
Removing unnecessary capabilities reduces exposure not only to CVE-2026-64531 but also to other kernel networking attack surfaces.
Use a verified live patch where operationally appropriate
A live patch may reduce emergency reboot pressure, but it should be treated as a vendor-specific remediation.
Überprüfen:
- exact kernel-build coverage;
- whether the CVE is present in the applied live-patch set;
- whether the patch is active in the running kernel;
- whether a later reboot could return the host to an unpatched disk kernel;
- whether kernel-module variants are covered;
- whether the vendor considers the patch equivalent to the upstream fix.
Several live-patching vendors announced CVE-2026-64531 coverage for selected kernel families, but availability varied by distribution and kernel flavour. (CloudLinux Blog)
Detection and Incident Response
CVE-2026-64531 does not provide defenders with one universal indicator of compromise.
Successful exploitation can use ordinary kernel interfaces, namespace creation and legitimate Netlink operations. Many systems do not record detailed Generic Netlink flow-management activity by default.
Detection should therefore combine several weak signals.
Unexpected Open vSwitch module loading
On a server with no legitimate OVS use, an unexpected openvswitch module load is suspicious.
Rückblick:
journalctl -k --since "7 days ago" |
grep -iE 'openvswitch|module'
Check current state:
lsmod | grep -E '^openvswitch\b'
Where auditd records kernel module operations:
ausearch -m KERNEL_MODULE -ts recent
The absence of a current module does not disprove earlier exploitation because an attacker may unload it or the host may have rebooted.
Unexpected namespace creation
Monitor untrusted users, web workers, CI jobs and service accounts for unexpected creation of user and network namespaces.
Relevant activities can include:
unshare
clone
clone3
setns
newuidmap
newgidmap
These operations are not inherently malicious. Browsers, containers and sandboxing systems use them legitimately. Detection therefore requires process, user, parent-process and workload context.
A web-server child process creating a user namespace and network namespace is more suspicious than a known rootless container runtime doing the same action under its documented service account.
Privileged-file modification
The public exploit’s final path modifies sudo configuration.
Monitor:
/etc/sudoers
/etc/sudoers.d/
/etc/passwd
/etc/shadow
/etc/group
/etc/security/
Example audit rules may be considered according to organizational policy:
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d -p wa -k sudoers_changes
File monitoring should include the process identity, executable, user namespace, container identity and parent process responsible for the modification.
Kernel warnings or crashes
Failed or partially successful attempts may generate:
- kernel warnings;
- invalid memory accesses;
- refcount warnings;
- Open vSwitch teardown errors;
- general protection faults;
- kernel panics;
- unusual networking failures.
Rückblick:
journalctl -k --since "24 hours ago" -p warning
A clean kernel log does not prove that exploitation did not occur. The public chain was designed to be comparatively reliable and does not necessarily require a visible crash.
Unexpected root transitions
Investigate processes that:
- change from an unprivileged identity to UID 0 without a normal authentication path;
- modify privileged files shortly after namespace creation;
- spawn shells after unusual networking or Netlink activity;
- execute
sudothrough newly created configuration; - operate from temporary directories or build workspaces;
- run under web, CI, package-build or shared-hosting accounts.
Preserve kernel and package evidence
During incident response, preserve:
Running kernel release
Installed kernel packages
Boot history
Module files and hashes
Module-load logs
Audit records
Namespace-related process telemetry
sudoers and authentication file metadata
Container runtime logs
CI runner logs
Kernel crash records
Live-patch state
Because the exploit depends on build-specific offsets, the exact kernel package and module binaries may be important for determining whether the public exploit supported the host.
Risk in Shared Hosting and CI Environments
CVE-2026-64531 is particularly concerning where untrusted or semi-trusted users already execute code locally.
Shared hosting
A compromised website may initially run only as a restricted application user. A local kernel privilege escalation can convert that restricted foothold into control over the entire server, including other tenants, credentials, databases and administrative interfaces.
CloudLinux highlighted this scenario directly: compromise of one website on a shared server could become root access to the host when the kernel and reachability conditions are present. (CloudLinux Blog)
CI runners
CI systems intentionally execute repository-controlled scripts, build processes and third-party dependencies. On shared or long-lived runners, an attacker who compromises a repository, dependency or build token may already possess the local execution needed to begin a privilege-escalation chain.
A root compromise can expose:
- signing keys;
- deployment credentials;
- cloud tokens;
- package registries;
- caches;
- neighbouring jobs;
- source code from other projects;
- container runtime sockets;
- host-level secrets.
Ephemeral runners reduce persistence opportunities but do not eliminate the risk if sensitive credentials are available during the job.
Developer workstations
Developer systems often enable unprivileged user namespaces and include container, virtualization or networking modules. They also hold source code, SSH keys, cloud credentials, package tokens and production-access tooling.
The local requirement therefore does not make the vulnerability irrelevant to endpoint security.
Multi-user research and education systems
University servers, security labs, build hosts and research clusters may provide shell access to many users. These environments fit the vulnerability’s basic local-user threat model particularly well.
Containers
The original researcher noted that the vulnerable path may be reachable from a container with suitable CAP_NET_ADMIN, but did not validate a complete container-escape exploit using the published PoC.
The distinction matters:
- reachability from a capable container is plausible and supported by the namespace model;
- a universal container-escape claim was not demonstrated;
- container runtime, namespace, module and kernel configuration affect the outcome;
- defenders should remove unnecessary capabilities and patch the host kernel rather than assume container boundaries resolve the issue. (Openwall)
Is the Userspace or DPDK Datapath Affected?
CVE-2026-64531 is located in the Linux kernel Open vSwitch datapath, specifically the flow-action conversion and validation code in net/openvswitch/flow_netlink.c.
Open vSwitch also supports userspace datapaths, including DPDK-based deployments. A system that exclusively uses a userspace datapath and does not contain reachable vulnerable kernel OVS code would not traverse this exact kernel path.
However, the deployment’s configured datapath type does not answer whether the vulnerable module is still installed and loadable. Administrators should verify both:
- which datapath production traffic uses; and
- whether an unprivileged process can independently load and interact with the kernel module.
Open vSwitch documentation distinguishes the Linux kernel datapath from userspace datapaths such as the netdev or DPDK path. (Open vSwitch Documentation)
Why Version Scanning Alone Produces False Results
A remote scanner cannot generally prove CVE-2026-64531 exposure from an HTTP banner or network service version.
The relevant facts are local:
- exact running kernel build;
- vendor patch history;
- Open vSwitch kernel configuration;
- module presence;
- module-load policy;
- namespace policy;
- available capabilities;
- live-patch state.
Even authenticated version scanning can fail when a vendor has backported the fix without adopting the upstream fixed version number.
A strong finding should therefore avoid statements such as:
Kernel is older than 6.1.178, therefore vulnerable.
A better finding is:
The host is running vendor kernel X.
The vendor identifies kernel package versions before Y as affected.
The running package is version Z.
The Open vSwitch module is present and loadable.
Unprivileged user namespaces are available.
No module block or verified live patch was observed.
The host is therefore considered exposed pending vendor confirmation.
This format separates evidence from inference and gives the remediation team something reproducible.
Patch Validation Matrix
| Validation question | Strong evidence | Weak or misleading evidence |
|---|---|---|
| Is a fixed kernel available? | Current vendor advisory or errata | Generic upstream version comparison |
| Is the fixed kernel installed? | Package-manager output | Repository web page alone |
| Is the fixed kernel running? | uname -r after reboot | Fixed package merely present in /boot |
| Is OVS kernel code available? | modinfo, kernel config and module-file inspection | lsmod alone |
| Can an ordinary user create namespaces? | Approved namespace policy review and controlled check | Assumption based on distribution name |
| Is module loading blocked? | modprobe -n -v openvswitch and configuration evidence | A blacklist file that has not been tested |
| Is a live patch active? | Vendor tool reports the CVE for the exact running build | Live-patch agent is installed |
| Has exploitation occurred? | Correlated process, audit, file and kernel evidence | No crash observed |
| Is remediation complete? | Fixed running kernel plus post-change verification | Update command exited successfully |
Evidence-Driven Validation with Penligent
CVE-2026-64531 illustrates why CVE validation should not be reduced to copying a version string into a vulnerability scanner.
A controlled workflow should collect the kernel identity, identify vendor backports, verify whether the OVS module is present or built in, evaluate namespace reachability, confirm mitigation state, document the active kernel after remediation, and retain the command output as evidence. The public exploit should remain outside production unless an organization has explicitly accepted the operational risk.
Penligent’s public materials describe an authorized, evidence-first pentesting workflow in which findings are validated through tool execution, supporting artifacts and reproducible remediation guidance. Its CVE-validation guidance similarly warns that a version string is not proof and recommends combining asset evidence, version analysis, behavior-based checks, patch guidance and false-positive handling. (Sträflich)
For CVE-2026-64531, an appropriate automated task should prioritize non-destructive checks such as:
Collect OS and running-kernel evidence
Identify the exact vendor kernel package
Check for built-in or loadable Open vSwitch support
Check module-load policy
Review user-namespace availability
Compare the package with the vendor advisory
Confirm whether a reboot or live patch is still required
Generate a remediation and retest record
The final report should clearly separate four states:
Affected
Potentially affected
Mitigated
Patched and verified
That distinction is more useful than a binary result generated from an upstream kernel number.
Frequently Asked Questions
Is CVE-2026-64531 remotely exploitable?
The demonstrated exploit begins with local code execution or an equivalent ability to interact with the kernel from an appropriate namespace.
It is not a conventional unauthenticated network-service vulnerability.
A remote attacker can still use it as a second-stage exploit after compromising a web application, CI job, container workload, restricted account or other service that provides local execution.
Does an attacker need root or sudo first?
No.
The published attack starts from an ordinary unprivileged local account under the tested conditions. The final PoC uses sudo configuration as part of its route to root execution, but initial sudo access is not required. (Openwall)
Does Open vSwitch need to be running?
Not necessarily.
A running ovs-vswitchd, an existing bridge and an already loaded module are not required when the kernel module is installed and can be loaded through its Generic Netlink aliases. (Hey, it’s Asim)
Ist lsmod | grep openvswitch a sufficient test?
No.
It shows whether the module is currently loaded. It does not show whether the module exists, is built into the kernel or can be automatically loaded later.
Use kernel configuration, modinfo, module-file inspection and module-policy validation.
Do SELinux or AppArmor stop the exploit?
The original researcher reported that SELinux and AppArmor did not block the tested exploit after the attacker obtained the necessary namespace-local CAP_NET_ADMIN.
Some AppArmor user-namespace policies can affect the initial namespace-creation route on specific releases, but they should not be treated as a universal fix for the underlying kernel bug. (Openwall)
Does disabling unprivileged user namespaces completely fix the problem?
No.
It can remove the easiest route for an ordinary local user, but it does not patch the vulnerable parser. Processes or containers that already possess the appropriate capability over a controlled network namespace may still reach the code.
Is every Linux kernel older than the listed fixed versions vulnerable?
No.
The enabling change was introduced and backported unevenly. Some older vendor kernels received it, while some newer-looking vendor kernels retained the former limit or already contain a backported fix.
Use the distribution’s CVE tracker and exact package build.
Can the public exploit be used for validation?
Only in a disposable and authorized laboratory.
It should not be used as a normal production validation check. The exploit manipulates kernel state and may modify privileged files or crash the system.
Is a failed PoC proof that the server is safe?
No.
The public PoC depends on architecture, kernel-build offsets, helper availability and its chosen final escalation path. The underlying vulnerability can exist even when that particular exploit build fails.
Is CVE-2026-64531 only a denial-of-service issue?
No.
Although malformed kernel structures can cause instability, the Linux CNA scoring and public exploit demonstrate confidentiality, integrity and availability impact, including local privilege escalation to root. Red Hat similarly describes possible sensitive-memory disclosure and LPE. (Red Hat Customer Portal)
Was this an unpatched zero-day at disclosure?
The issue was privately reported on June 19, 2026. The fix reached relevant stable branches before the full public write-up and PoC were released on July 28.
The disclosure therefore provided an upstream patch before publication of the complete exploit, although distribution packaging and rollout times varied. (Openwall)
Final Assessment
CVE-2026-64531 is a strong example of how a seemingly narrow length-field inconsistency can cross multiple security boundaries.
The vulnerability begins with a mismatch between two valid design assumptions:
- the complete Open vSwitch action stream may exceed 64 KiB;
- an individual Netlink nested attribute cannot exceed the 16-bit
nla_lenboundary.
Removing the older total-stream cap exposed a missing per-container check. Once an oversized generated CLONE action was closed with a truncated length, later consumers no longer agreed with the validated structure. Attacker-controlled bytes inside generated conntrack data could then be interpreted as independent actions.
The public exploit demonstrated that this discrepancy could be developed into kernel pointer disclosure, memory-reading and memory-modification primitives, credential corruption and root execution.
Organizations should prioritize remediation when affected Linux systems permit local code execution by untrusted or semi-trusted users, run shared workloads, host CI jobs, support containers, or hold sensitive credentials.
The correct response is:
- identify the exact running kernel;
- consult the vendor’s current advisory;
- determine whether Open vSwitch kernel code is present or built in;
- assess namespace and capability reachability;
- install and boot into a fixed kernel;
- block the module temporarily when it is unused;
- restrict unnecessary user namespaces and
CAP_NET_ADMIN; - investigate unexpected module loads, namespace activity and privileged-file changes;
- document patch validation with reproducible evidence;
- avoid running a public root exploit on production systems.
CVE-2026-64531 should not be closed merely because Open vSwitch is not listed as an active service. The decisive question is whether the vulnerable kernel path remains available to an unprivileged process—and whether the kernel currently running has actually been fixed.
German 
English 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew