Cloudanix VulnDB

CVE-2026-99025

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the system reports network flow details can freeze a busy server so hard that it crashes, interrupting network traffic until the machine is restarted.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

In openvswitch, ovs_flow_cmd_dump calls ovs_flow_stats_get per flow which issues repeated spin_unlock_bh releasing BH and running softirq backlog in the dump thread context; on loaded CPUs the backlog refills indefinitely with no reschedule point, starving the CPU and triggering soft lockup under voluntary preemption.

Why it matters to the business

Systems carrying thousands of datapath flows may experience sudden kernel panics during routine netlink operations, causing brief but complete loss of network datapath processing; low EPSS and two days since publication indicate limited immediate risk but still requires prompt patching in large Open vSwitch deployments.

How an attack unfolds

An attacker with sufficient privileges to issue netlink flow dump requests against an openvswitch datapath that already holds thousands of flows triggers the unbounded softirq absorption path, driving the dumping thread into a non-preemptible soft-lockup that panics the kernel.

How to fix it

Upgrade the Linux kernel to a version containing the fix that holds BH disabled across the entire ovs_flow_cmd_dump callback (matching the approach used by ctnetlink_dump_table); apply the change that prevents nested spin_unlock_bh from draining softirqs inside the RCU-protected walk.

How to confirm the fix worked

Confirm the kernel source contains the BH-off region around the full dump callback, verify that flow-dump operations on systems with >1000 flows no longer produce soft-lockup warnings, and check that the cursor walk remains bounded by table size without unbounded softirq absorption.

Typical attack path

  1. Obtain privileges capable of sending OVS netlink dump commands
  2. Ensure the target datapath already contains several thousand flows
  3. Issue repeated or large ovs_flow_cmd_dump requests
  4. Trigger soft lockup on a CPU handling packet load leading to panic

How to detect it

Search kernel logs and dmesg for soft lockup or watchdog messages mentioning netlink, ovs_flow, or flow dump on systems running openvswitch; correlate with high flow-count datapaths and recent netlink activity from privileged processes.

What your security team should do

  • Prioritize kernel updates on all Open vSwitch hosts within the next maintenance window given recent publication
  • Monitor kernel logs for soft lockup messages referencing ovs_flow_cmd_dump or netlink flow dump
  • Limit netlink access to trusted processes until patches are applied
  • Test datapath flow dumps under production flow counts after upgrade

The record

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.

Affected packages

Ecosystem Package Introduced Fixed