CVE-2026-64531

What it actually does

This flaw affects the Linux kernel Open vSwitch action-building path. Open vSwitch represents generated flow actions as netlink attributes whose individual length field is 16 bits. While the total generated action stream may legitimately exceed 64 KiB, the vulnerable code failed to reject oversized nested action containers, such as CLONE, CT, SAMPLE, DEC_TTL, or CHECK_PKT_LEN actions, whose encoded length cannot fit in the nested attribute length field. When such a container is closed, the length can be truncated, causing later validation, dump, teardown, or action-walking logic to interpret the byte stream differently than originally constructed. In practical terms, a low-privileged local attacker with access to Open vSwitch flow programming interfaces may be able to induce kernel-side misparsing of action data, potentially leading to memory corruption, incorrect action execution, resource lifetime errors, denial of service, or privilege escalation in the kernel context.

Why it matters to the business

Systems using affected Red Hat Enterprise Linux 9 kernel or real-time kernel packages with Open vSwitch enabled may be exposed to local privilege escalation or host instability if an attacker can submit crafted Open vSwitch flow actions. The operational risk is highest on virtualization, container networking, NFV, SDN, and private cloud platforms where Open vSwitch is used to enforce tenant or workload networking. Successful exploitation could let an attacker disrupt network switching, crash hosts, bypass expected isolation, or gain elevated control over the affected system. This issue is not currently listed in CISA KEV, is not known to be ransomware-used, has low EPSS, and has no public exploit maturity reported, but the named threat context associated with OVSwrap warrants monitoring in environments where untrusted users or workloads can influence OVS configuration.

How an attack unfolds

An attacker first needs local access or an equivalent path to interact with Open vSwitch configuration mechanisms, typically by sending crafted flow/action definitions through OVS tooling or netlink-facing control paths. The attacker constructs an action list containing deeply nested or oversized generated action attributes, such as CLONE, CT, SAMPLE, DEC_TTL, or CHECK_PKT_LEN containers, so that one nested container exceeds the 16-bit netlink attribute length limit while the overall action stream remains large enough to be accepted by the vulnerable logic. On vulnerable kernels, the oversized nested attribute can be closed with a truncated length. Later, when the kernel dumps, validates, executes, or tears down the action stream, it may walk the stream using the truncated structure and treat subsequent bytes as separate actions. Depending on memory layout and the exact action sequence, this can result in kernel crash, corrupted flow/action state, incorrect resource release, unintended packet actions, or possible code execution/privilege escalation. Activity attributed to the OVSwrap threat context should be treated as suspicious if it involves unusually large or complex Open vSwitch nested actions.

How to fix it

Upgrade affected Red Hat packages to fixed versions or later. For Red Hat Enterprise Linux 9, update kernel to 5.14.0-284.186.1.el9_2 or later as provided by RHSA-2026:51603. For Red Hat Enterprise Linux 9 real-time kernel deployments, update kernel-rt to 5.14.0-284.186.1.rt14.471.el9_2 or later as provided by RHSA-2026:51603. Reboot systems after kernel installation to ensure the fixed kernel is running. Where immediate patching is not possible, reduce exposure by limiting who can administer Open vSwitch, restricting access to OVS control sockets and management APIs, disabling unused Open vSwitch services/modules, preventing untrusted workloads from influencing OVS flow programming, and applying least privilege to network automation accounts. Because this is a kernel flaw, restarting Open vSwitch alone is not sufficient if the vulnerable kernel remains booted.

How to confirm the fix worked

Confirm the running kernel is fixed, not only that the package is installed. On Red Hat Enterprise Linux 9 systems, verify that the active kernel version is 5.14.0-284.186.1.el9_2 or later, or for real-time systems 5.14.0-284.186.1.rt14.471.el9_2 or later. Validate package state with the platform package manager and confirm the host has been rebooted into the updated kernel. Check whether Open vSwitch is loaded or active by reviewing kernel modules, OVS services, and datapath usage. Exposure is materially reduced if Open vSwitch is not installed, not loaded, and not used. In staging, test representative Open vSwitch flow creation, dumping, and deletion workflows after patching to ensure SDN, virtualization, or container networking functions continue normally.

Typical attack path

1. Obtain local access to a Linux host where affected Open vSwitch kernel functionality is available.
2. Gain permission or access to submit Open vSwitch flow/action configuration through OVS management tooling, a privileged helper, compromised automation, or exposed control plane integration.
3. Craft an Open vSwitch action list with oversized nested generated action attributes, commonly involving CLONE, CT, SAMPLE, DEC_TTL, CHECK_PKT_LEN, SET, or tunnel-related actions.
4. Submit the crafted flow/action payload to the kernel Open vSwitch datapath.
5. Trigger kernel processing, dumping, cleanup, or teardown of the malformed action stream so the truncated nested length causes the stream to be walked incorrectly.
6. Leverage the resulting kernel crash, memory corruption, resource lifetime confusion, or unintended action interpretation to cause denial of service, escape intended isolation, or attempt privilege escalation.

How to detect it

To assess prior exploitation, review logs and forensic artifacts around Open vSwitch flow programming and kernel instability. Relevant sources include system journal logs, kernel ring buffer output, audit logs, sudo and shell history for OVS administration commands, Open vSwitch service logs, orchestration or SDN controller logs, and crash dump repositories. Look for creation or deletion of unusually large or complex flows, repeated failed flow modifications, nested action usage involving CLONE, CT, SAMPLE, DEC_TTL, CHECK_PKT_LEN, SET, SET_TO_MASKED, or tunnel actions, and kernel warnings, oopses, panics, slab corruption, use-after-free symptoms, or crashes temporally associated with OVS operations. Since exploitation is local and may occur through legitimate OVS tools or automation, focus on unusual operators, unexpected source processes, abnormal command volume, and flow/action definitions inconsistent with normal network policy. In environments monitoring OVSwrap-related activity, correlate any such threat intelligence with local OVS management events and kernel crash telemetry. Absence of obvious indicators does not prove non-exploitation because successful kernel exploitation may leave minimal application-level logs.

• openvswitch
• openvswitch.ko
• ovs-vswitchd
• ovsdb-server
• ovs-ofctl add-flow
• ovs-ofctl mod-flows
• ovs-ofctl del-flows
• ovs-dpctl
• ovs-appctl
• clone(
• ct(
• sample(
• dec_ttl
• check_pkt_len
• set_field
• set_tunnel
• set_tunnel64
• kernel: openvswitch
• kernel: Oops
• kernel: BUG:
• kernel: general protection fault
• kernel: kernel panic
• kernel: KASAN
• kernel: slab-out-of-bounds
• kernel: use-after-free
• kernel: netlink
• /var/log/openvswitch/ovs-vswitchd.log
• /var/log/openvswitch/ovsdb-server.log
• /var/crash
• /sys/module/openvswitch

What your security team should do

• Prioritize patching hosts that run Open vSwitch in virtualization, container, SDN, NFV, or multi-tenant networking roles.
• Update Red Hat Enterprise Linux 9 kernel packages to RHSA-2026:51603 fixed versions and reboot into the fixed kernel.
• Inventory systems where Open vSwitch is installed, enabled, or where the openvswitch kernel module is loaded.
• Restrict Open vSwitch administration to trusted accounts and hardened automation paths; audit sudo rules, API access, and OVS control socket permissions.
• Monitor for unusually large, deeply nested, or failed Open vSwitch flow/action operations, especially involving clone, conntrack, sample, check-packet-length, decrement-TTL, tunnel, or masked-set actions.
• Review recent kernel crash, panic, oops, and Open vSwitch datapath logs for signs of malformed action handling or unexplained host instability.
• Treat activity linked to the OVSwrap threat context as higher priority if it coincides with Open vSwitch flow manipulation or kernel faults.
• If patching must be delayed, disable unused Open vSwitch components and isolate management interfaces from untrusted users and workloads.