https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 24 Oct 2026 18:05:26 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-99025 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>openvswitch: fix soft lockup in the netlink flow dump</p> <p>A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked.</p> <p>ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats-&gt;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&#39;s own context.</p> <p>The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box&#39;s packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU&#39;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.</p> <p>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 o…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>openvswitch: fix soft lockup in the netlink flow dump</p> <p>A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked.</p> <p>ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats-&gt;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&#39;s own context.</p> <p>The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box&#39;s packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU&#39;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.</p> <p>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 o…</p> https://db.gcve.eu/vuln/fkie_cve-2026-99025 https://db.gcve.eu/vuln/ghsa-25wv-6mrm-3cpw <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>openvswitch: fix soft lockup in the netlink flow dump</p> <p>A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked.</p> <p>ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats-&gt;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&#39;s own context.</p> <p>The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box&#39;s packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU&#39;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.</p> <p>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 o…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>openvswitch: fix soft lockup in the netlink flow dump</p> <p>A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked.</p> <p>ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats-&gt;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&#39;s own context.</p> <p>The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the box&#39;s packet load the backlog refills as fast as it drains, so the dumping thread becomes that CPU&#39;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.</p> <p>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 o…</p> https://db.gcve.eu/vuln/ghsa-25wv-6mrm-3cpw