UBUNTU-CVE-2026-74555: Medium severity ubuntu/linux-hwe-edge vulnerability

In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisisas disk-wake race Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sasresumehanosync() to avoid a deadlock: the PHYERESUMETIMEOUT handler, running on the HA event workqueue, calls sasdeformport() -> sasdestructdevices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sasresumeha() -> sasdrainwork() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisisas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYERESUMETIMEOUT notification to after sasdrainwork(). By then the host resume is about to complete, so device removal through devicelink no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sasresumeha() (the draining variant) in hisisas and remove sasresumehanosync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sassuspenddevices() calls sasnotifylldddevgone() for each device, which sets dev->lldddev to NULL. When scsiunblockrequests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SASDEVICEUNKNOWN (mapped to DIDBADTARGET), and pm8001 returns SASPHYDOWN (mapped to DIDNOCONNECT). Both complete directly via scsidone() without entering SCSI EH. This is identical in both the old and new ordering since lldddevgone runs during suspend, before resume. The reorder only affects when the PHYERESUMETIMEOUT handler runs (synchronized by sasdrainwork() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path.