CVE-2026-99025 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
openvswitch: Behebung eines Soft-Lockups beim Netlink-Flow-Dump
Ein Produktions-Rechenknoten mit einigen tausend Datapath-Flows geriet in einen Soft-Lockup innerhalb eines einzelnen Netlink-Flow-Dumps und verursachte ein Kernel-Panic.
ovs_flow_cmd_dump() ruft ovs_flow_stats_get() für jeden Flow auf, der ausgegeben wird, und gibt stats->lock mit spin_unlock_bh() einmal pro CPU frei, die den Flow berührt hat. Jede Freigabe ist ein lokaler bh_enable(), und jeder davon führt das pending softirq backlog im Kontext des Dumping-Threads aus.
Das skb begrenzt die Flows, die ein Callback ausgibt, nicht jedoch die von ihm absorbierte Softirq-Arbeit. Auf einer CPU, die den Paketlast der Box trägt, wird das Backlog so schnell aufgefüllt, wie es geleert wird, sodass der Dumping-Thread zur softirq-Engine dieser CPU wird. Er schläft nie ein und hat keinen Reschedule-Punkt, daher kann unter freiwilliger Preemption nichts die CPU von ihm wegnehmen: weder ksoftirqd, das der Kernel aufweckt, um die Arbeit zu übernehmen, noch den Stopper-Thread, den der Softlockup-Detektor zur Aktualisierung seines Zeitstempels abfertigt.
Stattdessen wird BH über den gesamten Callback hinweg blockiert (held off), so wie es ctnetlink_dump_table() tut, damit das verschachtelte spin_unlock_bh() das Ableiten von softirqs stoppt. Die Schleife läuft bereits unter rcu_read_lock() und kann nicht schlafen. Was sie aufgibt, ist die Preemption unter CONFIG_PREEMPT, da eine BH-off-Region außerhalb von PREEMPT_RT nicht preemptible ist. Die Region bleibt kurz: Das skb begrenzt die Flows, die ein Callback ausgibt, und leere Buckets kosten keinen skb-Speicherplatz, werden aber bei jedem Dump einmal besucht, da der Cursor nur vorwärts bewegt wird. Die Tabelle wächst beim Einfügen (insert) und schrumpft nur beim Löschen (flush), daher ist der Durchlauf durch die größte Flow-Anzahl begrenzt, die das Datapath je gehalten hat. Das Softirq-Backlog, das der Callback zuvor absorbiert hat, hat überhaupt keine Begrenzung.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.