OVSwrap: The Linux Kernel Flaw That Turns Local Access Into Root

A 13-year-old integer truncation bug, a removed safety limit, and Linux namespace features have combined to create a reliable privilege-escalation path across widely used distributions.

A newly disclosed vulnerability in the Linux kernel’s Open vSwitch datapath could allow an ordinary local user to gain complete root privileges on affected systems.

Tracked as CVE-2026–64531, with a CVSS score of 7.8, the vulnerability has been named OVSwrap by security researcher Asim Manizada, who publicly disclosed it on July 28, 2026.

Although it is classified as a local privilege-escalation vulnerability, its potential impact should not be underestimated.

On shared servers, cloud infrastructure, development environments, CI runners, container hosts, and multi-user systems, “local user” does not necessarily mean a trusted employee sitting at a terminal. It may mean a compromised website account, a malicious customer workload, an exploited application, or an attacker who has already obtained limited access through an unrelated vulnerability.

OVSwrap can potentially turn that limited foothold into control of the entire server.

What makes the vulnerability particularly significant is that the affected kernel code may be reachable even when administrators do not believe Open vSwitch is actively running.

No configured Open vSwitch bridge may be required. The ovs-vswitchd userspace daemon does not necessarily need to be running. The Open vSwitch kernel module may not even appear in lsmod.

The attack surface can still be present.

The essential facts

OVSwrap is a memory-corruption vulnerability in the Open vSwitch component of the Linux kernel.

The most important points are:

• The vulnerability exists in the kernel datapath, not in the ovs-vswitchd userspace daemon.
• An ordinary user may be able to reach the vulnerable code through Linux user and network namespaces.
• The Open vSwitch module may be automatically loaded even if it is not already visible in memory.
• The underlying unsafe operation reportedly existed for approximately 13 years.
• A change introduced in March 2025 removed a size limit that had unintentionally prevented exploitation.
• The public proof of concept includes information for roughly 800 x86–64 kernel builds.
• The upstream fix was released in stable kernel trees on July 24, 2026.
• Installing a vendor-patched kernel remains the preferred remediation.

The released proof of concept is explicitly described as destructive and should not be executed casually on production infrastructure.

What is Open vSwitch?

Open vSwitch, commonly abbreviated as OVS, is a programmable software switch used extensively in virtualized and software-defined networking environments.

It can connect virtual machines, containers, physical interfaces, and virtual networks while applying detailed rules to network traffic.

Open vSwitch is commonly associated with technologies such as:

• OpenStack
• Kubernetes networking
• Container platforms
• Network virtualization
• Software-defined networking
• Cloud computing infrastructure
• Virtual machine hosting

The platform includes both userspace components and kernel-level functionality.

The ovs-vswitchd daemon manages and configures virtual switching behavior in userspace. The kernel datapath handles packets and executes flow actions inside the Linux kernel, where performance-sensitive operations can be completed more efficiently.

OVSwrap is located in this kernel datapath.

That distinction is fundamental because stopping or disabling the userspace daemon does not necessarily remove the vulnerable kernel code from the system.

Why the kernel location matters

Kernel vulnerabilities operate at one of the most privileged levels of the operating system.

A userspace process is normally constrained by memory boundaries, permissions, and the security context assigned to it. The Linux kernel, by contrast, controls processes, memory, filesystems, devices, network interfaces, credentials, and access-control decisions.

Memory corruption inside the kernel can therefore have consequences far beyond the component in which the original error appears.

In the case of OVSwrap, a flaw in the processing of network-flow actions may ultimately allow an attacker to manipulate the credentials of a process and obtain root privileges.

The vulnerability demonstrates a recurring truth in operating-system security: the apparent function of a subsystem does not limit the impact of a bug inside it.

A network-processing vulnerability can become a credential-manipulation vulnerability because both operations occur within the same privileged kernel environment.

An ordinary user may be able to reach privileged networking code

Under normal circumstances, configuring network interfaces and installing Open vSwitch flows requires elevated privileges such as CAP_NET_ADMIN.

Linux namespaces complicate that assumption.

Namespaces allow processes to operate inside isolated views of system resources. User namespaces, in particular, can allow an unprivileged user on the host to appear as root inside a private namespace without becoming root on the host itself.

When unprivileged user namespaces are enabled, an ordinary user may be able to create a private user namespace and a corresponding network namespace.

Inside that isolated environment, the user can obtain CAP_NET_ADMIN for the namespace.

This capability does not normally provide administrative control over the host network. It is intended to be restricted to the isolated network namespace.

However, it may still provide access to kernel interfaces and code paths that contain vulnerabilities.

On affected systems, this namespace capability can reportedly be used to reach the vulnerable Open vSwitch flow-installation path.

The user does not begin with host-level administrative privileges. The vulnerability is what potentially allows the attacker to cross that boundary.

Why an empty lsmod result may provide false reassurance

One of the most operationally important aspects of OVSwrap is the possibility of automatic kernel-module loading.

An administrator may run lsmod, fail to find openvswitch, and conclude that the system is not exposed.

That conclusion may be incorrect.

If the Open vSwitch kernel module is installed but not currently loaded, attempting to resolve its Generic Netlink family name may cause the operating system to load it automatically.

In practical terms, a module does not always need to be resident in memory before an attacker begins interacting with the relevant kernel interface.

The distinction between “not loaded” and “cannot be loaded” is therefore critical.

A proper exposure assessment should answer four separate questions:

1. Is the Open vSwitch kernel module installed?
2. Can the module be loaded automatically?
3. Are unprivileged user namespaces enabled?
4. Has the running vendor kernel incorporated the security fix?

Checking only whether the module is currently visible addresses the first few seconds of system state, not the module’s potential availability.

A vulnerability that remained dormant for 13 years

The unsafe operation behind OVSwrap reportedly existed in the Open vSwitch code for approximately 13 years.

It did not suddenly appear in 2026.

Instead, an older bug became exploitable after a more recent change removed a limit that had unintentionally prevented the vulnerable condition from being reached.

This is an important distinction.

Software often contains dormant vulnerabilities that cannot be triggered because another validation rule, size limit, or architectural restriction blocks the necessary input.

When that surrounding condition changes, the older vulnerability becomes exposed.

That appears to be what happened with OVSwrap.

The importance of the 16-bit length field

Open vSwitch stores generated flow actions using Netlink attributes.

Netlink is a Linux communication mechanism used by kernel components and userspace applications. Netlink messages contain structured attributes describing operations, parameters, and nested data.

Each Netlink attribute contains a field called nla_len, which represents the length of the attribute.

The field is 16 bits wide.

A 16-bit unsigned value can represent a maximum value of 65,535. Consequently, a single nested Netlink attribute cannot correctly describe a length greater than 65,535 bytes.

The unsafe assignment at the center of OVSwrap allowed a larger generated size to be written into this smaller field.

For years, another limit prevented that from becoming exploitable.

Open vSwitch imposed a 32 KiB cap on the total generated action stream. Because the total stream could not grow beyond that limit, an individual nested action could not cross the 65,535-byte threshold.

The vulnerable truncation remained present, but the dangerous input size was unreachable.

The March 2025 change that altered the risk

In March 2025, the 32 KiB limit was removed.

The cap had caused unpredictable operational failures, including problems in large OpenStack environments. Removing it addressed a genuine reliability and scalability concern.

Unfortunately, it also removed the barrier that prevented generated nested actions from exceeding the range of the 16-bit length field.

The older truncation bug became reachable.

Review discussions surrounding the change reportedly focused on reliability problems and failures experienced by users. They did not identify the security consequences of allowing the action stream to grow beyond the downstream field’s representable range.

This type of interaction is particularly difficult to detect during code review.

The modified limit may appear unrelated to the vulnerable assignment. The unsafe conversion may exist elsewhere in the codebase and may have operated without visible problems for more than a decade.

Yet the security of the entire path depended on the relationship between the two.

How the OVSwrap overflow works

At a high level, an attacker supplies a very large nested Open vSwitch action containing hundreds of connection-tracking sub-actions.

On x86–64 systems, each of these sub-actions expands when processed by the kernel. The generated nested action eventually exceeds 65,535 bytes.

Open vSwitch then attempts to store the resulting size in the 16-bit nla_len field.

Because the actual value is larger than the field can represent, it is truncated. The value wraps around and appears much smaller than the real generated object.

Later code trusts that incorrect length.

Instead of continuing to parse data from the legitimate end of the nested action, the parser resumes from an offset inside attacker-controlled connection-tracking data.

The attacker can place forged Open vSwitch actions at that location.

This creates a parser-confusion condition in which data controlled by the attacker is interpreted as legitimate kernel-level OVS actions.

Why reliability makes OVSwrap more serious

Kernel memory-corruption exploits are often unreliable.

They may require precise heap layouts, repeated allocation patterns, race conditions, or timing-sensitive operations. A failed attempt may simply crash the host.

OVSwrap appears to avoid some of those difficulties.

The incorrect parser landing point is reportedly deterministic and remains inside the same contiguous buffer. The exploit therefore does not need extensive heap grooming to arrange objects in a useful pattern.

Manizada characterized the vulnerability as having “logic-bug-grade reliability.”

That description is significant.

A traditional memory-corruption vulnerability may behave unpredictably because the attacker is manipulating memory layouts indirectly. A deterministic parser offset behaves more like a logical error: the same malformed structure repeatedly directs the parser toward the same controlled location.

The public proof of concept also contains pre-built records for roughly 800 exact x86–64 kernel builds. For builds not already covered, it reportedly attempts to derive necessary information dynamically from kernel symbols or BPF Type Format data.

This substantially increases the practical importance of the disclosure.

From a wrapped length to root access

The published technical analysis describes an exploit chain based on three capabilities obtained through the parser confusion:

• A kernel-pointer disclosure using a forged OUTPUT action
• An arbitrary kernel-memory read using a forged tunnel SET action
• A targeted decrement involving the cleanup of a forged tun_dst pointer

The first capability helps defeat kernel address randomization by revealing useful memory locations.

The second allows the exploit to inspect kernel memory and locate relevant data structures.

The third provides a limited mechanism for modifying selected values.

These capabilities are combined to locate the credentials associated with a host process.

On modern Linux kernels, the exploit can then target credential fields such as fsuid and fsgid, reducing their values to zero.

On Linux, user ID zero and group ID zero correspond to root.

The vulnerability therefore transforms a malformed Open vSwitch action into a mechanism for changing the security identity of a process.

The proof of concept is destructive

The publicly released proof of concept should not be treated as a harmless vulnerability scanner.

It is explicitly described as destructive.

When exploitation succeeds, it reportedly:

• Corrupts an active kernel credential
• Modifies /etc/sudoers.d or /etc/sudoers
• Opens a root shell
• Leaves processes running
• Preserves Open vSwitch state to avoid unsafe teardown

The exploit also requires specific supporting components, including OVS connection-tracking functionality, the FTP conntrack helper, and sudo.

Those requirements reduce the number of directly exploitable systems. However, the researcher’s test matrix suggests that the required conditions exist by default across numerous popular distributions.

Executing this proof of concept on a production system could damage the operating system, destabilize the kernel, alter security configuration, and complicate incident-response evidence.

Vendor-supported detection and validation methods are preferable.

Which Linux distributions were affected during testing?

The researcher’s non-exhaustive testing reportedly found default-configuration exploitation on tested versions of:

• AlmaLinux 9 and 10
• Alpine Linux 3.22 through 3.24
• Amazon Linux 2023
• Arch Linux
• CentOS Stream 9 and 10
• Debian 12 and 13
• Fedora 42 through 44
• Gentoo
• Kali Linux 2026.1
• Linux Mint 22.3
• NixOS
• openSUSE Tumbleweed
• Pop!_OS
• Rocky Linux 9 and 10
• Ubuntu 22.04

This should not be interpreted as a complete list of vulnerable systems.

It is a test matrix, not a universal vulnerability database. Results can vary according to kernel package, architecture, vendor backports, namespace settings, loaded modules, security policies, and installed networking components.

Conversely, the absence of a distribution from the list does not prove that it is safe.

Systems that behaved differently

Some older systems reportedly retained code paths that were not exploitable through this particular route.

Tested examples included:

• Amazon Linux 2
• Debian 11
• Rocky Linux 8
• Ubuntu 20.04

Ubuntu’s more recent releases also demonstrated how mandatory access-control policies can influence exploitability.

On tested Ubuntu 24.04 systems, AppArmor blocked the direct creation of the required namespaces. However, the proof of concept reportedly included an alternative AppArmor profile-based method that restored access to the vulnerable path.

Stock Ubuntu 26.04 blocked the ordinary-user route during testing. When its AppArmor restriction for user namespaces was disabled, the tested systems became exploitable.

These results show why vulnerability assessment cannot rely exclusively on a distribution name or version number.

AppArmor policy, namespace configuration, module loading, kernel backports, and package revisions all affect the final security posture.

The first fixed upstream kernel versions

The upstream correction was released in stable kernel trees on July 24, 2026.

The first fixed upstream releases identified in the disclosure are:

• Linux 5.15.212
• Linux 6.1.178
• Linux 6.6.145
• Linux 6.12.97
• Linux 6.18.40
• Linux 7.1.5

End-of-life kernel series from 6.13 through 6.17, along with 6.19 and 7.0, are not expected to receive fixes through the upstream stable process.

These version numbers should not be used as the only method of determining whether a system is protected.

Linux distributions routinely backport security fixes into kernels that retain older-looking version numbers. A vendor kernel may therefore include the correction without matching one of the listed upstream releases.

The opposite can also be true for custom, unsupported, or independently maintained kernels.

The operating-system vendor’s security advisory, vulnerability tracker, and package changelog should be treated as the primary sources of truth.

How administrators should respond

The preferred remediation is to install a corrected kernel package from the system’s vendor and reboot the host into the updated kernel.

Installing a package without rebooting is insufficient when the vulnerable kernel remains active in memory.

After rebooting, administrators should verify that the expected kernel version is actually running.

Where a corrected kernel is not yet available, the appropriate interim mitigation depends on whether Open vSwitch is required.

When Open vSwitch is not needed, future loading of the module can be blocked with a modprobe rule:

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

This rule prevents future module-loading attempts through the normal mechanism.

It does not remove an openvswitch module that is already active. A resident module must be safely unloaded or removed by rebooting the system.

Operational teams should test module removal carefully, particularly on infrastructure where Open vSwitch may be supporting active virtual networking.

Are user namespaces a sufficient mitigation?

Disabling unprivileged user namespaces can block the attack route available to an ordinary local user.

This may be a useful temporary hardening measure, especially on servers that do not require unprivileged namespace creation.

It is not a complete replacement for patching.

A container or another process that already possesses CAP_NET_ADMIN inside an attacker-controlled network namespace may still be able to reach the vulnerable kernel path.

The container-based direction was described as theoretically reachable, although it was not demonstrated in the released proof of concept.

Environments that need to retain both Open vSwitch and user namespaces may require additional compensating controls. The disclosed research reportedly includes an emergency BPF-based guard, but such measures should be independently reviewed and treated as temporary defenses rather than permanent corrections.

Which environments face the greatest risk?

OVSwrap should receive especially high priority in environments where local access cannot be considered fully trusted.

Examples include:

• Shared web-hosting platforms
• Public cloud infrastructure
• University and research servers
• Multi-user development systems
• Continuous-integration runners
• Container hosts
• Virtualization clusters
• Systems running customer-supplied code
• Servers processing third-party workloads

On these systems, a low-privilege account may already represent an adversarial position.

An attacker could compromise one website, application, build process, container, or user account through an unrelated vulnerability. OVSwrap could then provide the second stage required to escape that restricted context and gain control of the host.

CloudLinux summarized the shared-hosting risk by explaining that the “local user” may be an attacker who has already compromised a single hosted site.

The kernel flaw is what can turn a one-account incident into a whole-server compromise.

The broader lesson for software security

OVSwrap is more than another entry in a vulnerability database.

It illustrates how the security of mature software may depend on limits that were never intended to be security controls.

The original 32 KiB cap existed to constrain generated action streams. It eventually caused reliability problems and unpredictable failures, particularly in large deployments.

Removing the limit appeared to be a reasonable engineering decision.

However, the limit also prevented data from reaching a dangerous integer boundary elsewhere in the system.

It acted as an accidental security barrier.

This pattern appears frequently in long-lived software:

1. A legacy field has a restricted size.
2. Another guard prevents input from reaching that maximum.
3. The guard becomes operationally inconvenient.
4. Engineers remove or relax it.
5. A dormant overflow, truncation, or parser bug becomes reachable.

The correct lesson is not that old limits should never be changed.

It is that removing any limit requires a review of the assumptions made by every downstream component.

Security reviewers should ask:

• Does a later field use a smaller integer type?
• Can nested data grow faster than the outer structure?
• Does another parser trust the stored length?
• Can generated data exceed the size of the original input?
• Was previously unreachable code written under assumptions that are no longer true?
• Does removing the limit expose an untested range of values?

In the OVSwrap case, the dangerous mismatch was between an expanding generated action stream and a 16-bit field that could not accurately represent its size.

Frequently asked questions about OVSwrap

What is OVSwrap?

OVSwrap is the name given to CVE-2026–64531, a memory-corruption vulnerability in the Linux kernel’s Open vSwitch datapath. Under affected configurations, it may allow a local user to gain root privileges.

Is OVSwrap a remote vulnerability?

The disclosed route is primarily a local privilege escalation. An attacker generally needs the ability to execute code as a local user or inside a suitable workload environment before attempting to reach the vulnerable kernel interface.

Is a system safe when Open vSwitch is not configured?

Not necessarily. The vulnerability exists in the kernel module, and the module may be loaded automatically. An OVS bridge and a running ovs-vswitchd process may not be required.

Does an empty lsmod result mean the host is protected?

No. It only indicates that the module is not currently visible as loaded. Administrators must also determine whether the module is installed, autoloadable, and blocked by policy.

Does disabling unprivileged user namespaces fix OVSwrap?

It can block the ordinary local-user route described in the disclosure, but it may not prevent access from containers or processes that already possess suitable namespace capabilities. Installing a patched kernel remains the recommended solution.

Can the upstream kernel version confirm whether a system is safe?

Not by itself. Distribution kernels frequently include backported security fixes. Administrators should consult the vendor’s official advisory and package information.

Is the public proof of concept safe to run?

No. It is described as destructive and modifies live kernel credentials and sudo-related files. It may also leave processes and networking state behind. It should not be treated as a routine production scanner.

What is the best remediation?

Install a vendor-patched kernel, reboot into it, and verify the running version. Where Open vSwitch is unnecessary, block the module from loading and ensure it is not already active.

Final assessment

OVSwrap combines several conditions that are individually familiar but collectively dangerous:

• A long-standing integer truncation bug
• A later change that removed an accidental safeguard
• A privileged kernel networking subsystem
• Unprivileged namespace functionality
• Automatic kernel-module loading
• A public exploit designed for hundreds of kernel builds

The result is a credible path from ordinary local access to root privileges across a broad range of Linux environments.

Defenders should respond directly.

Install the patched vendor kernel. Reboot into it. Confirm the running package. Block the Open vSwitch module where it is unnecessary. Review unprivileged user-namespace exposure. Prioritize shared, multi-tenant, cloud, and containerized hosts.

Most importantly, do not assume that an unused service represents an unreachable kernel attack surface.

With OVSwrap, the absence of a configured virtual switch, a running daemon, or a visible module may provide false reassurance.

The decisive question is whether the vulnerable kernel path can be reached.

On many default-configured Linux systems, the available research suggests that it can.

Source: https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html