# CVE-2026-99025: openvswitch: fix soft lockup in the netlink flow dump


- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 23 Oct 2026
- **Updated:** 23 Oct 2026
- **Also known as:** AZL-110879, BELL-CVE-2026-99025, DEBIAN-CVE-2026-99025, GHSA-25wv-6mrm-3cpw, UBUNTU-CVE-2026-99025

## What is CVE-2026-99025?

CVE-2026-99025 is a vulnerability in Linux, published on 23 Oct 2026. 

### Official description

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.

## Which versions are affected by CVE-2026-99025?


## How do I fix CVE-2026-99025?

Upgrade to a fixed version.

## Is CVE-2026-99025 being exploited?

There is no known exploitation of CVE-2026-99025 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-99025 and fix it if it is affected.

What it is: CVE-2026-99025 is a vulnerability in Linux, published on 23 Oct 2026. 
Exploitation: There is no known exploitation of CVE-2026-99025 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-99025/ (Markdown: https://insights.sbomify.com/CVE-2026-99025/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-99025
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-99025
- OSV: https://osv.dev/vulnerability/CVE-2026-99025

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-99025/
Summaries are generated and may contain mistakes; the official description above is the record.
