{"apiVersion":"1.0","identifier":"CVE-2026-99202","description":"In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix SMP IO deadlock during HA resume smp_execute_task_sg() calls pm_runtime_get_sync() on the host before issuing an SMP command. When that command is itself issued from the HA resume path, the get_sync() deadlocks: it waits for the ongoing resume (the device is RPM_RESUMING), while the resume is blocked in sas_drain_work() waiting for that same SMP IO to complete. The deadlock needs an expander-attached SATA disk. During sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for such a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Direct-attached SATA resets through lldd_control_phy() and SSP devices use TMFs, so neither hits this. Replace the get_sync()/put_sync() pair with pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only needs to hold off autosuspend while the SMP is in flight, and it must not try to resume the host: a sync resume issued from the HA resume path itself is what deadlocks, and by the time sas_resume_ha() runs, hw_init has already reinitialized the hardware, so the device is accessible without one. The usage reference is still required. Discovery work normally runs inside an event worker-s PM reference, taken at sas_notify_port_event() notify time and held until the handler has flushed the disco queue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN from within the revalidation worker itself, and flush_workqueue() does not wait for work items queued during execution, so that chained revalidation runs with no outer PM reference - without the get_noresume(), its SMP could race autosuspend. For the BSG path, sas_smp_handler() is the only caller which may find the host autosuspended: expander SMP requests do not go through any SCSI device request queue, so nothing else in that path holds the host awake. Resume it there with pm_runtime_resume_and_get() and check the result.","publishedAt":"2026-10-28T11:17:41","lastModifiedAt":"2026-10-30T13:21:52","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-99202","cvssScore":null,"cvssVector":null,"epssProbability":0.00174,"riskScore":null,"affectedProduct":"Linux kernel","affectedVersions":"unknown","vulnerabilityType":"Kernel","operatingSystems":[],"links":{"self":"https://www.redsauce.net/api/cves/CVE-2026-99202","webPages":{"es":"https://www.redsauce.net/es/cves/CVE-2026-99202","en":"https://www.redsauce.net/en/cves/CVE-2026-99202","fr":"https://www.redsauce.net/fr/cves/CVE-2026-99202","pt":"https://www.redsauce.net/pt/cves/CVE-2026-99202","de":"https://www.redsauce.net/de/cves/CVE-2026-99202","sk":"https://www.redsauce.net/sk/cves/CVE-2026-99202","el":"https://www.redsauce.net/el/cves/CVE-2026-99202"},"source":"https://nvd.nist.gov/vuln/detail/CVE-2026-99202"}}