GHSA-25WV-6MRM-3CPW
Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-99025"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-23T13:17:25Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix soft lockup in the netlink flow dump\n\nA production compute node carrying a few thousand datapath flows hit a\nsoft lockup inside a single netlink flow dump and panicked.\n\novs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it\nemits, and that releases stats-\u003elock with spin_unlock_bh() once per\nCPU that has touched the flow. Every release is a local_bh_enable(),\nand each one runs the pending softirq backlog in the dumping thread\u0027s\nown context.\n\nThe skb bounds the flows one callback emits, but not the softirq work\nit absorbs. On a CPU that carries the box\u0027s packet load the backlog\nrefills as fast as it drains, so the dumping thread becomes that CPU\u0027s\nsoftirq engine. It never sleeps and it has no reschedule point, so\nunder voluntary preemption nothing can take the CPU away from it:\nneither the ksoftirqd the kernel woke to take the work over, nor the\nstopper thread the softlockup detector dispatches to refresh its\ntimestamp.\n\nHold BH off across the whole callback instead, the way\nctnetlink_dump_table() does, so the nested spin_unlock_bh() stop\ndraining softirqs. The loop already runs under rcu_read_lock() and\ncannot sleep. What it gives up is preemption under CONFIG_PREEMPT,\nsince a BH-off region is not preemptible outside PREEMPT_RT. The\nregion stays short: the skb caps the flows one callback emits, and\nempty buckets cost no skb space but are each visited once per dump, as\nthe cursor only moves forward. The table grows on insert and shrinks\nonly on flush, so the walk is bounded by the largest flow count the\ndatapath has held. The softirq backlog the callback used to absorb has\nno bound at all.",
"id": "GHSA-25wv-6mrm-3cpw",
"modified": "2026-10-23T15:31:35Z",
"published": "2026-10-23T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99025"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55f12552b00a34ca7ab5cf2d2b5ed02f8f06a965"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80db24f3c16fdeef85460d9d66a4aae7a9cb92b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aaaaf87ea99b8766c9a8aa0e71aa42e6bc8a5320"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b872de585edff534056c65ba30970b68499fca14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c995c52eba1926a5e82823fa5573a6f1b1010e5d"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.