← All Advisories

Linux Kernel SCSI Host Recovery Leaves SDEV_CANCEL Queue Unkicked, Causing Requests to Stall and the Device to Hang on Removal

Last refreshed2026-10-10

Status: UPDATED  |  Advisory ID: CVE-2026-64003

Key Details

CVECVE-2026-64003
CVSS Score / Version7.5 (High) / CVSS v3.1
Updated2026-10-08
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS Proseattack vector is network; attack complexity is low; privileges required is none; user interaction is none; scope is unchanged; confidentiality impact is none; integrity impact is none; availability impact is high.
Affected productsLinux Kernel
Classified asCWE-772 (Missing Release of Resource after Effective Lifetime)

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux Kernel
SubsystemsOT Supporting Infrastructure
SectorsAll Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues

While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not

set the requeue list for a requeued command to be kicked in the future.

The expectation is a call to scsi_run_host_queues() will kick all SCSI

devices once the recovery state is cleared.

However, scsi_run_host_queues() uses shost_for_each_device() which uses

scsi_device_get() and so will ignore devices in a partially removed

state like SDEV_CANCEL. But these devices may also have requeued

requests, leaving their requests stuck from not being kicked and causing

the removal process of the device to hang.

scsi_run_host_queues() needs to run against more devices than the macro

shost_for_each_device() allows. Instead of using the too limiting

scsi_device_get() state checks, only ignore devices in SDEV_DEL state or

when unable to acquire a reference. Attempt to run the queues for all

other devices when scsi_run_host_queues() is called. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-64003
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-64003