CVE-2026-99202 in Linux
Zusammenfassung
von VulDB • 28.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
scsi: libsas: Behebung eines SMP-IO-Deadlocks während der HA-Wiederherstellung (HA resume)
smp_execute_task_sg() ruft pm_runtime_get_sync() für den Host auf, bevor ein SMP-Befehl ausgegeben wird. Wenn dieser Befehl selbst aus dem Pfad zur HA-Wiederherstellung heraus ausgegeben wird, führt get_sync() zu einem Deadlock: Es wartet darauf, dass die laufende Wiederherstellung abgeschlossen ist (das Gerät befindet sich im Zustand RPM_RESUMING), während die Wiederherstellung in sas_drain_work() blockiert und auf den Abschluss desselben SMP-IO-Vorgangs wartet.
Der Deadlock erfordert einen an einen Expander angeschlossenen SATA-Datenträger. Während sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() wird ATA_EH_RESET angefordert, und die harte Rücksetzung eines solchen Datenträgers erfolgt über SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Bei direkt angeschlossenen SATA-Rücksetzungen durch lldd_control_phy() sowie bei SSP-Geräten, die TMFs verwenden, tritt dies nicht auf.
Ersetzen Sie das Paar get_sync()/put_sync() durch pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() muss lediglich verhindern, dass ein automatisches Ruhezustand (autosuspend) eingeleitet wird, solange der SMP-Vorgang in Bearbeitung ist; es darf nicht versuchen, den Host wiederzuholen. Ein synchroner Wiederherstellungsvorgang, der aus dem HA-Wiederherstellungspfad selbst ausgegeben wird, verursacht genau diesen Deadlock. Zum Zeitpunkt des Ausführungsbeginns von sas_resume_ha() wurde die Hardware durch hw_init bereits neu initialisiert, sodass das Gerät ohne eine solche Maßnahme zugänglich ist.
Die Verweiszählung für die Nutzung (usage reference) bleibt weiterhin erforderlich. Der Discovery-Arbeitsprozess läuft normalerweise innerhalb einer PM-Referenz eines Ereignisarbeiters, die bei sas_notify_port_event() zum Zeitpunkt des Benachrichtigungsereignisses aufgenommen wird und bis der Handler die Disco-Warteschlange geleert hat, gehalten wird. sas_rediscover_ex_phy() stellt jedoch DISCE_REVALIDATE_DOMAIN aus dem Revalidierungsarbeiter selbst wieder in die Warteschlange ein, und flush_workqueue() wartet nicht auf Arbeitsaufgaben, die während der Ausführung eingereiht wurden; daher läuft diese verkettete Revalidierung ohne äußere PM-Referenz. Ohne get_noresume könnte es beim SMP zu einem Wettlauf (Race Condition) mit dem automatischen Ruhezustand kommen.
Für den BSG-Pfad ist sas_smp_handler() der einzige Aufrufer, bei dem der Host im automatischen Ruhezustand gefunden werden kann: Expander-SMP-Anforderungen gehen nicht durch eine SCSI-Geräteanforderungswarteschlange, daher hält nichts anderes in diesem Pfad den Host wach. Wecken Sie ihn dort mit pm_runtime_resume_and_get() auf und prüfen Sie das Ergebnis.
VulDB is the best source for vulnerability data and more expert information about this specific topic.