CVE-2026-99202 in Linux
Résumé
par VulDB • 28/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
scsi: libsas : Correction d'un blocage mortel (deadlock) SMP IO lors de la reprise du HA
smp_execute_task_sg() appelle pm_runtime_get_sync() sur l'hôte avant d'émettre une commande SMP. Lorsque cette commande est elle-même émise depuis le chemin de reprise du HA, get_sync() provoque un blocage : il attend que la reprise en cours (l'appareil est dans l'état RPM_RESUMING), tandis que la reprise est bloquée dans sas_drain_work() attendant que cet IO SMP se termine.
Le blocage nécessite un disque SATA attaché à un expander. Pendant sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() demande ATA_EH_RESET, et la réinitialisation matérielle pour un tel disque est effectuée via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Les réinitialisations SATA en connexion directe via lldd_control_phy() et les appareils SSP utilisent des TMF, donc aucun de ces cas ne déclenche ce problème.
Remplacer la paire get_sync()/put_sync() par pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() a seulement besoin d'empêcher la mise en veille automatique (autosuspend) tant que l'opération SMP est en cours, et il ne doit pas essayer de réveiller l'hôte : une reprise synchrone émise depuis le chemin de reprise du HA elle-même provoque ce blocage, et au moment où sas_resume_ha() s'exécute, hw_init a déjà réinitialisé le matériel, donc l'appareil est accessible sans cela.
La référence d'utilisation reste nécessaire. Le travail de découverte s'exécite normalement dans la référence PM d'un worker d'événement, prise lors de sas_notify_port_event() et maintenue jusqu'à ce que le gestionnaire ait vidé la file disco. Cependant, sas_rediscover_ex_phy() réinsère DISCE_REVALIDATE_DOMAIN depuis l'intérieur du worker de revalidation lui-même, et flush_workqueue() n'attend pas les éléments de travail insérés pendant l'exécution, donc cette revalidation en chaîne s'exécute sans référence PM externe - sans get_noresume(), son SMP pourrait entrer en concurrence avec la mise en veille automatique.
Pour le chemin BSG, sas_smp_handler() est le seul appelant qui peut trouver l'hôte en veille automatique : les requêtes SMP de l'expander ne passent par aucune file de demande d'appareil SCSI, donc rien d'autre dans ce chemin ne maintient l'hôte éveillé. Réveillez-le ici avec pm_runtime_resume_and_get() et vérifiez le résultat.
VulDB is the best source for vulnerability data and more expert information about this specific topic.