CVE-2026-68123

What it actually does

This flaw is in the Linux kernel Open vSwitch datapath handling for packets that combine truncation, userspace delivery, and GSO segmentation. The vulnerable logic stores a truncation delta based on the original packet length and later reuses it after a large GSO packet has been split into smaller segments. For an individual segment, the stored cut length can exceed the segment length, causing an integer underflow in the length passed to skb_zerocopy(). The likely technical outcomes are kernel memory corruption, out-of-bounds memory access, kernel warning/oops, or host crash; depending on kernel build, memory layout, and reachable code paths, stronger impacts such as privilege escalation cannot be ruled out.

Why it matters to the business

Systems using Linux kernel Open vSwitch for virtualization, container networking, SDN, NFV, or cloud switching could experience host-level instability or network outages if crafted traffic reaches a vulnerable OVS action path. A successful attack may disrupt virtual machine or container connectivity, trigger kernel panics, and reduce availability of workloads sharing the affected host. This issue is newly published, is not currently listed in CISA KEV, and has no known public exploit maturity in the provided data, but kernel networking flaws in widely deployed switching paths should still be prioritized for exposed multi-tenant or untrusted-traffic environments.

How an attack unfolds

An attacker first needs traffic to traverse a Linux host using the kernel Open vSwitch datapath and an OVS rule/action sequence that can both truncate a packet and send it to userspace, such as controller/upcall, sampling, or other userspace-facing actions. The attacker then sends traffic that is represented in the kernel as a GSO skb, commonly possible from a VM, container, local workload, or virtual NIC path with segmentation offload enabled. When OVS applies the truncation action and subsequently segments the GSO packet, the vulnerable code reuses the original truncation delta for each smaller segment. For a sufficiently small segment, the cut length becomes larger than the segment length, causing an underflow when calculating the amount of data to copy to userspace. That malformed length reaches skb_zerocopy(), potentially causing memory corruption or a kernel fault. In practice, exploitation is most plausible from an attacker who can inject traffic through OVS-controlled virtual networking rather than from arbitrary Internet traffic, unless the vulnerable OVS flow path is reachable from external ingress.

How to fix it

Apply the vendor-provided Linux kernel update that includes the Open vSwitch fix for GSO userspace truncation handling. No exact fixed package versions were provided in the input, so track the advisory from the relevant Linux distribution, kernel vendor, appliance vendor, or cloud image provider and upgrade to the first kernel build that contains the fix. After updating, reboot into the fixed kernel or ensure an applicable live patch is active; merely installing the package is not sufficient if the old kernel remains running. Where immediate patching is not possible, reduce exposure by avoiding OVS rules that combine truncation with userspace delivery for untrusted traffic, disabling or limiting GSO/TSO/GRO offloads on affected OVS-facing interfaces where operationally acceptable, restricting untrusted tenant or container traffic paths, and monitoring for kernel instability. Mitigations should be treated as temporary because the vulnerable code is in the kernel datapath.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the fix. Validate with uname -a, distribution package metadata, vendor security advisories, and change logs for the Open vSwitch kernel datapath fix. If source validation is available, confirm the OVS truncation handling stores a maximum preserved length rather than a delta and uses a no-truncation sentinel such as U32_MAX while bounding consumers against the current skb length. Review active OVS flows with ovs-ofctl and datapath behavior with ovs-dpctl to identify whether truncation and userspace actions are in use. In test environments only, reproduce representative OVS truncation/userspace/GSO traffic before and after patching and verify the fixed kernel does not emit kernel warnings, oopses, or crashes.

Typical attack path

1. Identify or gain access to a workload, VM, container, or network path whose traffic crosses a Linux kernel Open vSwitch datapath.
2. Ensure traffic matches an OVS flow/action path involving packet truncation and later delivery to userspace, such as controller/upcall or sampling behavior.
3. Generate large packets that are handled as GSO skbs, often by relying on TCP segmentation offload or virtual NIC offload behavior.
4. Craft packet sizes so that after GSO segmentation, at least one segment is smaller than the previously stored truncation delta.
5. Trigger the vulnerable OVS userspace delivery path, causing an underflowed copy length to be passed to skb_zerocopy().
6. Leverage the resulting kernel memory corruption or fault to crash the host networking stack, panic the kernel, or potentially pursue further exploitation depending on kernel defenses.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, persistent journald records, crash dumps, hypervisor logs, and Open vSwitch logs around periods of unexplained network disruption or host reboot. Focus on OVS hosts where the openvswitch kernel module is loaded and where flows send truncated packets to userspace. Search dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, vmcore crash traces, kdump output, and OVS logs under /var/log/openvswitch/ for kernel warnings, BUG/Oops traces, panics, or faults involving openvswitch, queue_gso_packets(), queue_userspace_packet(), skb_zerocopy(), GSO, truncation, or userspace packet delivery. Correlate any crash with high-volume or unusual large-packet traffic from VMs, containers, tunnel endpoints, or virtual interfaces. Also review OVS/controller telemetry for bursts of packet-in/upcall/sample events immediately before a fault. Absence of these artifacts does not prove non-exploitation because a kernel panic may truncate logs unless persistent logging or crash dumping is enabled.

• openvswitch
• skb_zerocopy
• queue_gso_packets
• queue_userspace_packet
• OVS_ACTION_ATTR_TRUNC
• GSO userspace truncation
• kernel BUG
• kernel oops
• general protection fault
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• /var/log/openvswitch/ovs-vswitchd.log
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /proc/vmcore

What your security team should do

• Prioritize patching Linux hosts that run Open vSwitch in virtualization, container, SDN, NFV, or multi-tenant networking roles.
• Inventory systems with the openvswitch kernel module loaded or OVS bridges/datapaths active, and determine whether untrusted traffic can reach those datapaths.
• Identify OVS rules or controller behaviors that use truncation together with userspace delivery, packet-in, upcall, sampling, or similar actions.
• Where patching is delayed, consider temporarily disabling risky OVS action combinations or interface offloads such as GSO/TSO/GRO on affected paths after performance testing.
• Increase monitoring of kernel logs, crash dumps, OVS logs, and controller events for signs of skb_zerocopy, openvswitch, or GSO-related faults.
• Treat unexplained kernel panics on OVS hosts as potentially security-relevant until crash traces and traffic conditions are reviewed.
• Track vendor advisories for exact fixed kernel versions because no fixed versions were supplied in the input.