CVE-2026-99207 in Linux
Zusammenfassung
von VulDB • 29.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
scsi: target: Deaktivieren von Interrupts während des Halts von delayed_cmd_lock
target_do_delayed_work() nimmt dev->delayed_cmd_lock mit einem einfachen spin_lock(). Es wird aus system_percpu_wq ausgeführt, sodass Interrupts aktiviert bleiben, solange die Sperre gehalten wird. Jede andere Übernahme dieser Sperre verwendet spin_lock_irqsave(): target_handle_task_attr() und transport_complete_ordered_sync() in target_core_transport.c sowie target_non_ordered_release() in target_core_device.c.
Dies war sicher, solange jeder Aufrufer von transport_complete_task_attr() im Prozesskontext lief: target_complete_ok_work() aus target_completion_wq, transport_complete_qf() aus dev->qf_work_queue und transport_generic_request_failure() aus den Submit- und Execute-Pfaden.
Seit dem Commit 06933066d88a ("scsi: target: Add support for completing commands from backend context") trifft dies nicht mehr zu. Bei complete_type=1 auf einem Fabric, das direct_compl_supp festlegt, läuft target_complete() mit target_complete_ok_work() inline im Completion-Kontext des Backends, was target_complete_cmd_with_sense() als "Kann aus Interrupt-Context aufgerufen werden" dokumentiert. Für iblock ist dies der bio end_io.
target_complete_ok_work() beginnt mit transport_complete_task_attr(), das delayed_cmd_lock auf zwei Arten nimmt:
- Jeder ORDERED-Befehl wird von target_handle_task_attr() in dev->delayed_cmd_list eingeordnet und dort von target_do_delayed_work() abgearbeitet, der ihn als SCF_TASK_ORDERED_SYNC markiert. Seine Fertigstellung verläuft daher über transport_complete_ordered_sync(). - Ein SIMPLE-Befehl, der abgeschlossen wird, während ein ORDERED-Befehl aussteht, reduziert den letzten Verweis auf das getötete dev->non_ordered, und percpu_ref_put() führt dann target_non_ordered_release() im abschließenden Kontext aus.
Beide nehmen die Sperre und rufen bei wartenden Befehlen schedule_work(&dev->delayed_cmd_work) auf, was in system_percpu_wq einreihet, d.h. auf der CPU, die den Abschluss übernommen hat. Weitere Abschlüsse für dieselbe Warteschlange werden typischerweise ebenfalls dort zugestellt, sodass eine eintreffende Anforderung während des Halts der Arbeit durch die Sperre endlos darauf wartet (spinning).
Das Erreichen dieses Zustands erfordert complete_type=1, was nicht standardmäßig aktiviert ist (vhost-scsi, das einzige Fabric mit direct_compl_supp, verwendet standardmäßig TARGET_QUEUE_COMPL), ein Backend, dessen I/O aus Interrupt-Context abgeschlossen wird, und ORDERED-Befehle vom Initiator. Linux virtio_scsi-Gäste senden nur VIRTIO_SCSI_S_SIMPLE und nutzen niemals den geordneten Pfad; jeder Gast, der das ORDERED-Auftragsattribut verwendet, was vhost-scsi akzeptiert, tut dies jedoch.
target_do_delayed_work() ist ein Work-Item und läuft immer im Prozesskontext, daher reicht spin_lock_irq().
Durch Inspektion gefunden; kein Laufzeitbericht. Ein einzelner ORDERED-Befehl durchläuft beide Übernahmen der Sperre, sodass bei CONFIG_PROVE_LOCKING die erste über direkten Abschluss abgeschlossene Operation einen Bericht über inkonsistente Sperrzustände für delayed_cmd_lock erzeugen sollte (hardirq oder softirq, abhängig davon, wo das Backend abschließt).
VulDB is the best source for vulnerability data and more expert information about this specific topic.