CVE-2026-31508

What it actually does

CVE-2026-31508 is a race condition in the Linux kernel Open vSwitch datapath teardown path. During OVS port removal, ovs_netdev_detach_dev() clears the IFF_OVS_DATAPATH flag before device unregistration is fully complete. On preemptible kernels, especially PREEMPT_RT builds, another teardown path can observe the cleared flag, proceed through netdev_destroy(), and free the net_device while unregister logic is still using it. This creates a use-after-free condition in kernel networking code, commonly surfacing as a general protection fault or kernel oops in functions such as dev_set_promiscuity(), ovs_netdev_detach_dev(), dp_device_event(), and unregister_netdevice_many_notify(). The likely practical impact is local denial of service through kernel crash or instability; because the bug is a kernel memory lifetime flaw, confidentiality and integrity impact are theoretically possible if an attacker can reliably shape kernel heap state, but no public exploit maturity is reported.

Why it matters to the business

Systems using Linux kernel Open vSwitch can become unstable or crash when OVS-backed network devices are removed under the vulnerable race condition. This is most operationally relevant for virtualization, container, NFV, SDN, and private-cloud platforms where OVS ports are frequently created and destroyed. A successful exploit could interrupt host networking, disrupt workloads, force node reboots, and reduce availability of services dependent on virtual switching. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS with a flat 30-day trend, which lowers broad internet exploitation urgency; however, the CVSS score is high because exploitation occurs in kernel context and can have severe host-level consequences once a local attacker has the needed privileges.

How an attack unfolds

An attacker needs local access with the ability to manipulate Open vSwitch or network link state, typically through privileges such as CAP_NET_ADMIN, administrative access to a network namespace, or control over tooling that creates and deletes OVS ports. The attacker repeatedly triggers OVS port teardown, for example by deleting OVS-backed interfaces or datapath ports through iproute2, ovs-vsctl, or netlink operations. On a vulnerable kernel, ovs_netdev_detach_dev() may clear the OVS datapath flag and then be preempted before unregistration finishes. A competing netdevice destroy path can then free the underlying net_device too early. When the original teardown path resumes, it dereferences stale kernel memory, causing a use-after-free. In observed failure modes this results in a kernel oops/general protection fault and may crash the host or destabilize networking; in a more advanced exploitation scenario, an attacker would attempt to win the race repeatedly while grooming kernel memory to influence the freed object.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Open vSwitch netdevice teardown race. Because no exact fixed package versions were provided, use the security advisories from the operating system or appliance vendor and update to the first kernel build that explicitly references this CVE or the Open vSwitch fix described as avoiding netdev release before teardown completes. Prioritize systems running Open vSwitch, PREEMPT_RT/real-time kernels, virtualization hosts, Kubernetes or container networking nodes using OVS, SDN/NFV infrastructure, and multi-tenant systems where non-root users may gain CAP_NET_ADMIN inside namespaces. If immediate patching is not possible, reduce exposure by restricting local administrative access, limiting CAP_NET_ADMIN delegation, disabling unneeded Open vSwitch functionality, preventing untrusted users from creating network namespaces or OVS ports, and scheduling controlled restarts after kernel updates. Kernel live patching may not be sufficient unless the vendor explicitly states this race is covered.

How to confirm the fix worked

Confirm the running kernel is no longer within the affected vendor range and that the installed package changelog or advisory includes the Open vSwitch teardown fix for this CVE. Validate both the installed kernel package and the actively booted kernel with commands such as uname -a and distribution package queries. Check whether the openvswitch kernel module is loaded with lsmod or modinfo, and inventory hosts using OVS bridges or datapaths with tools such as ovs-vsctl show and ip link. After remediation, perform controlled OVS port create/delete testing in a non-production or maintenance window and verify that kernel logs do not show general protection faults, kernel oops messages, or call traces involving openvswitch teardown functions. For PREEMPT_RT systems, give special attention to testing under realistic OVS churn because the race is more likely to manifest under preemption.

Typical attack path

1. Obtain local access to a Linux system that has the Open vSwitch kernel module/datapath in use.
2. Gain or already possess permission to create, modify, or delete OVS/network devices, commonly via CAP_NET_ADMIN or equivalent administrative control.
3. Create or identify an OVS-backed network interface or port attached to an OVS datapath.
4. Repeatedly trigger OVS port or link deletion through netlink, iproute2, or OVS management commands to exercise the vulnerable teardown path.
5. Race the clearing of the IFF_OVS_DATAPATH flag against netdevice destruction on a vulnerable/preemptible kernel.
6. Cause use-after-free during device unregistration, leading to kernel oops, host crash, or network stack instability.
7. Optionally attempt repeated triggering and heap shaping to explore whether the kernel memory corruption can be converted into stronger impact.

How to detect it

Look for evidence of kernel crashes, oopses, or general protection faults during Open vSwitch port deletion or network device teardown. Primary log sources include dmesg, journald/kern.log, /var/log/messages, /var/log/kern.log, crash dumps, kdump/vmcore artifacts, audit logs, shell history, sudo logs, and OVS logs such as ovs-vswitchd.log. Search for call traces containing openvswitch functions, especially ovs_netdev_detach_dev(), dp_device_event(), dev_set_promiscuity(), unregister_netdevice_many_notify(), rtnl_dellink(), and netlink sendmsg activity from tools such as ip or OVS management utilities. Correlate timestamps of kernel oopses with commands that delete links, ports, bridges, or datapaths, including ip link delete, ovs-vsctl del-port, ovs-vsctl del-br, and namespace teardown operations. Because no public exploit is reported and this race can also be triggered by legitimate automation, treat matching logs as suspicious when they coincide with unusual local user activity, unexpected CAP_NET_ADMIN use, repeated port deletion loops, or crashes on systems where OVS churn is not routine.

• Oops: general protection fault
• general protection fault, probably for non-canonical address
• RIP: 0010:dev_set_promiscuity
• dev_set_promiscuity+0x8d/0xa0
• ovs_netdev_detach_dev
• ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]
• dp_device_event
• dp_device_event+0x41/0x80 [openvswitch]
• unregister_netdevice_many_notify
• rtnl_dellink
• rtnetlink_rcv_msg
• netlink_sendmsg
• Comm: ip
• [openvswitch]
• IFF_OVS_DATAPATH
• PREEMPT_RT
• Kdump: loaded
• ip link delete
• ovs-vsctl del-port
• ovs-vsctl del-br

What your security team should do

• Patch or upgrade kernels on systems running Open vSwitch, prioritizing virtualization hosts, container networking nodes, NFV/SDN infrastructure, and PREEMPT_RT kernels.
• Inventory where Open vSwitch is enabled or where the openvswitch kernel module is loaded, rather than treating all Linux systems as equally exposed.
• Restrict CAP_NET_ADMIN, network namespace creation, OVS administration, and local shell access to trusted users only until patched.
• Review kernel logs from vulnerable systems for recent oopses or general protection faults involving openvswitch, dev_set_promiscuity, ovs_netdev_detach_dev, dp_device_event, or unregister_netdevice_many_notify.
• Add SIEM detections for kernel crash traces matching the known failure pattern and correlate with local commands or netlink activity that delete OVS ports or links.
• For platforms with frequent automated OVS port churn, consider temporarily reducing unnecessary interface recreation or moving workloads off vulnerable hosts before maintenance.
• Track vendor advisories for exact fixed kernel package versions because upstream kernel fixes may be backported without changing to a visibly newer upstream version.
• Do not prioritize as an internet-facing mass-exploitation issue based solely on EPSS or KEV status, but treat it as high impact where local administrative boundaries or multi-tenant network administration exist.