scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race
In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas 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 PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.1.183, 6.12.103, 6.18.44, 6.6.151, 7.1.8
- CVEs
- CVE-2026-74555
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 20:10 UTC · Revision 1
Source evidence
scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race
core-osv · Original sourcePublished 15 Aug 2026, 12:28 UTC
In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas 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 PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in
osv:CVE-2026-74555
Kernel
Fixed versions: 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8
Complete source record
{
"id": "e9a2659bef90fbd663c31ab95b75cf3053e65f8cef2054717d6d4c4d1ecc9294",
"url": "https://osv.dev/vulnerability/CVE-2026-74555",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race",
"summary": "In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 (\"scsi: libsas: Don't always drain event workqueue for HA resume\") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas 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 PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in",
"evidence": "osv:CVE-2026-74555",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.1.183",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.151",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.103",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.44",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.8",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-74555",
"aliases": [
"CVE-2026-74555"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "fbefe22811c3140a686e407e114789ebf328a9a2"
},
{
"fixed": "09357f067122e2e28ec52e27013a1660a1571618"
},
{
"fixed": "e50a6523a603594a6d92cdecfe11997d639410a3"
},
{
"fixed": "c391b5899dd46485a5893696c12ae3e95a3a7325"
},
{
"fixed": "9e24b47ef81d43b3fb1b14294f09991640c79fcc"
},
{
"fixed": "b9c44a14062093e9fc2d6bddc696cfceadb482d7"
},
{
"fixed": "3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74555.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.17.0"
},
{
"fixed": "6.1.183"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.151"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.103"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.44"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.8"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74555.json"
}
}
],
"modified": "2026-10-28T02:30:31.981560260Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/09357f067122e2e28ec52e27013a1660a1571618",
"https://git.kernel.org/stable/c/3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845",
"https://git.kernel.org/stable/c/9e24b47ef81d43b3fb1b14294f09991640c79fcc",
"https://git.kernel.org/stable/c/b9c44a14062093e9fc2d6bddc696cfceadb482d7",
"https://git.kernel.org/stable/c/c391b5899dd46485a5893696c12ae3e95a3a7325",
"https://git.kernel.org/stable/c/e50a6523a603594a6d92cdecfe11997d639410a3",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74555.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-74555",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74555.json"
}
},
"related_cves": [
{
"value": "CVE-2026-74555",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 498903,
"published_at": "2026-08-15T12:28:00.729+00:00"
}