CVE-2026-99202

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.