---
id: "CVE-2026-99025"
kind: "vulnerability"
aliases: ["CVE-2026-99025"]
title: "Linux kernel: Open vSwitch flow dump can soft-lock a CPU and panic"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["hypervisors", "kubernetes", "linux-kernel", "open-vswitch", "runtime"]
not_affected_if: ["low-flow-count", "no-openvswitch-module"]
published_at: "2026-10-23T13:17:25+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T04:54:30+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99025", "first_seen_at": "2026-10-23T21:57:33+00:00"}]
---

# Linux kernel: Open vSwitch flow dump can soft-lock a CPU and panic

A netlink flow dump in the Open vSwitch datapath can hold a CPU in softirq processing so long that the kernel reports a soft lockup and panics on busy hosts with many datapath flows. The sources describe a denial of service from a local or administrative netlink dump, not a code execution or data read.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel builds in the upstream stable tree (unknown in sources)
- `lsmod | grep openvswitch` to confirm the openvswitch module is loaded
- `ovs-dpctl dump-flows` on a node with thousands of flows to see whether the dump path is used

## Fix

- Update the Linux kernel to a stable release that includes the upstream openvswitch fix (exact version unknown in sources)
- Reboot into the patched kernel after updating

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99025

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

openvswitch: fix soft lockup in the netlink flow dump

A production compute node carrying a few thousand datapath flows hit a
soft lockup inside a single netlink flow dump and panicked.

ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it
emits, and that releases stats->lock with spin_unlock_bh() once per
CPU that has touched the flow. Every release is a local_bh_enable(),
and each one runs the pending softirq backlog in the dumping thread's
own context.

The skb bounds the flows one callback emits, but not the softirq work
it absorbs. On a CPU that carries the box's packet load the backlog
refills as fast as it drains, so the dumping thread becomes that CPU's
softirq engine. It never sleeps and it has no reschedule point, so
under voluntary preemption nothing can take the CPU away from it:
neither the ksoftirqd the kernel woke to take the work over, nor the
stopper thread the softlockup detector dispatches to refresh its
timestamp.

Hold BH off across the whole callback instead, the way
ctnetlink_dump_table() does, so the nested spin_unlock_bh() stop
draining softirqs. The loop already runs under rcu_read_lock() and
cannot sleep. What it gives up is preemption under CONFIG_PREEMPT,
since a BH-off region is not preemptible outside PREEMPT_RT. The
region stays short: the skb caps the flows one callback emits, and
empty buckets cost no skb space but are each visited once per dump, as
the cursor only moves forward. The table grows on insert and shrinks
only on flush, so the walk is bounded by the largest flow count the
datapath has held. The softirq backlog the callback used to absorb has
no bound at all.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_