CVE-2026-99025
Beschrijving NL
In de Linux-kernel is de volgende kwetsbaarheid verholpen:
openvswitch: verhelpt soft lockup in de netlink flow dump
Een productiecomputerknooppunt dat enkele duizenden datastromen verwerkte, is vastgelopen.
Er treedt een soft lockup op tijdens een flow dump van een enkele netlink, met een panic als gevolg. ovs_flow_cmd_dump() roept ovs_flow_stats_get() aan voor elke flow die het bevat.
zendt uit, en dat geeft stats->lock vrij met spin_unlock_bh() eenmaal per
CPU die de stroom heeft beïnvloed. Elke release is een local_bh_enable(),
en elk van hen verwerkt de in behandeling zijnde softirq-achterstand in de dumping-thread.
eigen context. De skb begrenst de flows die een callback uitzendt, maar niet het softirq-werk.
Het absorbeert. Op een CPU die de pakketbelasting van de box verwerkt, ontstaat de achterstand.
Het geheugen wordt net zo snel bijgevuld als het leegloopt, waardoor de dumpthread de verantwoordelijkheid van die CPU wordt.
softirq-engine. Het slaapt nooit en het heeft geen verplaatsingspunt, dus
onder vrijwillige voorkeursrecht kan niets de CPU ervan afhouden:
noch de ksoftirqd de kernel ontwaakte om het werk over te nemen, noch de
stopper draad die de softlockup detector verzendt om zijn
timestamp. Houd BH uit over de hele callback in plaats daarvan, de manier
ctnetlink_dump_table() doet, dus de geneste spin_unlock_bh() stopt
afvoer softirqs. De lus loopt al onder rcu_read_lock() en
kan niet slapen. Wat het opgeeft, is de preëmptie onder CONFIG_PREEMPT.
aangezien een BH-off-regio niet kan worden onderbroken buiten PREEMPT_RT.
De regio blijft kort: de skb beperkt de stromen die één callback uitzendt, en
Lege emmers nemen geen skb-ruimte in beslag, maar worden elk slechts één keer per lediging bezocht, omdat
De cursor beweegt alleen vooruit. De tabel groeit bij het invoegen en krimpt bij het invoegen.
alleen bij doorspoelen, dus de wandeling wordt begrensd door het grootste aantal stromen.
Het datapad is in de wachtstand gebleven. De softirq-backlog die de callback gebruikte om te absorberen, is nu beschikbaar.
Geen enkele grens.
Origineel (Engels) tonen
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.