Strix
73.1K

CVE-2026-99025

UnknownEPSS 0.17%

Last modified

CVE-2026-99025 is a vulnerability of currently unknown severity. 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. EPSS estimates a 0.17% chance of exploitation in the next 30 days.

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.

Metrics

EPSS Probability
0.17%

6.2th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < ef77dd59cb7b7b0ac0bedd3fe9ee7a8acd8a58f2; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < 9ffb9897b39037a688ae01d0b3aea4ccce27dd75; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < 5b6a8bbdcdd7d0fddee466c1c7fe5b7f30aa392c; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < c995c52eba1926a5e82823fa5573a6f1b1010e5d; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < b872de585edff534056c65ba30970b68499fca14; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < 55f12552b00a34ca7ab5cf2d2b5ed02f8f06a965; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < 80db24f3c16fdeef85460d9d66a4aae7a9cb92b4; >= 63e7959c4b9bd6f791061c460a22d9ee32ae2240, < aaaaf87ea99b8766c9a8aa0e71aa42e6bc8a5320
LinuxLinux3.16

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-99025?
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.
How severe is CVE-2026-99025?
Severity scoring for CVE-2026-99025 is pending analysis. The EPSS model estimates a 0.17% probability of exploitation in the next 30 days.
How do I fix CVE-2026-99025?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-99025?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST