CVE-2026-64003 in Linuxinfo

Summary

by MITRE • 07/19/2026

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.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 07/19/2026

This vulnerability exists within the Linux kernel's SCSI subsystem where the scsi_run_host_queues function fails to properly process all SCSI devices during host recovery operations. The issue stems from the function's reliance on shost_for_each_device() macro which employs scsi_device_get() for device iteration, thereby excluding devices in partially removed states such as SDEV_CANCEL. When a SCSI host enters recovery state, the scsi_mq_requeue_cmd() function does not properly set requeue lists for commands that need future processing, creating a scenario where these commands become permanently stuck in limbo.

The fundamental technical flaw occurs because scsi_run_host_queues() operates under restrictive device state filtering that prevents it from accessing devices in transitional states like SDEV_CANCEL, even though these devices may still contain pending requests requiring queue processing. This design limitation creates a deadlock condition where the removal process of SCSI devices cannot complete properly since their associated requests remain unprocessed and stuck in the queue system. The problem specifically affects the multi-queue SCSI implementation where command requeuing operations depend on proper queue execution to maintain system stability and prevent resource starvation.

The operational impact of this vulnerability manifests as device removal hangs and potential system instability during SCSI host recovery scenarios. When devices transition through partial removal states while commands are still queued, the system cannot properly clean up these resources leading to resource leaks and potentially complete system freezes. This affects storage subsystem reliability and can cause extended downtime during device management operations. The vulnerability particularly impacts environments with high I/O workloads where SCSI device removal or replacement operations are frequent.

The mitigation strategy involves modifying scsi_run_host_queues() to bypass the overly restrictive device state checks that currently exclude SDEV_CANCEL and similar transitional states. Instead of relying on scsi_device_get() which filters out certain device states, the function should process all devices except those in the final SDEV_DEL state or when reference acquisition fails. This approach aligns with common security practices for resource management where systems must handle cleanup operations even during transitional device states. The solution follows principles similar to those outlined in CWE-400 for resource leak prevention and ATT&CK technique T1489 for system recovery operations, ensuring that queue processing occurs for all relevant devices regardless of their exact state during host recovery procedures. This change maintains system stability while preventing the deadlock conditions that arise from incomplete device removal processes.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!