CVE-2026-93781 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Do not block on tag allocation in scsi_eh_lock_door()
scsi_eh_lock_door() is called from scsi_restart_operations() while the host is still in the SHOST_RECOVERY state, i.e. before the host is switched back to SHOST_RUNNING and scsi_run_host_queues() restarts the queues. It allocates a request via scsi_alloc_request() with no flags, so blk_mq_get_tag() may block waiting for a free sched tag when all tags are already in use.
Those tags can be held by commands that were just requeued by scsi_eh_flush_done_q() during error handling. Such commands cannot be dispatched until the host leaves SHOST_RECOVERY and scsi_run_host_queues() is called - which only happens *after* scsi_eh_lock_door() returns.
This forms a circular dependency:
- scsi_eh_lock_door(), running in the SCSI error handler thread, waits for a sched tag held by a requeued command;
- the requeued command cannot complete and release its sched tag until the error handler thread leaves scsi_restart_operations() and restart the queues.
For devices with a single driver tag (e.g. USB storage) it is a guaranteed deadlock and I/O that can never be submitted. This problem has also been reproduced in our environment.
Locking the door is a best-effort operation, and scsi_eh_lock_door() already returns silently when the request allocation fails. Pass BLK_MQ_REQ_NOWAIT to scsi_alloc_request() so the allocation fails instead of blocking when no tag is available. This breaks the circular dependency and allows the error handler to finish restarting the queues, after which the pending commands are dispatched normally.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel SCSI subsystem contains a critical deadlock vulnerability within the device recovery mechanism, specifically in the scsi_eh_lock_door function. This issue arises during the host reset process when the storage controller is transitioning from an error state back to normal operation. The core of the problem lies in how request tags are allocated and managed while the host remains in the SHOST_RECOVERY state. During this phase, the system attempts to lock the door as part of the recovery sequence before fully restarting I/O queues. This process involves allocating a new SCSI request using scsi_alloc_request without specifying any special flags, which defaults to blocking behavior if resources are unavailable.
The technical flaw stems from a circular dependency involving block layer tags and SCSI error handling threads. When all available scheduler tags are currently in use by commands that have been requeued during previous error handling operations, the allocation call blocks indefinitely. These specific commands cannot be dispatched or completed because they must wait for the host to exit the SHOST_RECOVERY state. However, exiting this state requires scsi_eh_lock_door to complete successfully and return control so that scsi_run_host_queues can restart the queues. Consequently, the error handler thread waits for a tag held by a command that is itself waiting for the error handler to finish its current task. This creates an unresolvable deadlock where neither side can proceed.
The operational impact of this vulnerability is severe, particularly for devices with limited tagging capabilities such as USB storage drives which typically support only a single driver tag. In these scenarios, the deadlock is guaranteed whenever tags are exhausted during recovery, leading to permanent I/O suspension and potential system hangs or unresponsiveness regarding those storage devices. Even in systems with more complex multi-tag hardware, prolonged blocking can cause significant latency spikes and degrade overall storage performance until external intervention or timeout mechanisms eventually break the cycle. This represents a denial of service condition where legitimate input/output operations are permanently stalled due to internal kernel logic errors rather than external attacks or resource exhaustion by user applications.
From a classification perspective, this vulnerability aligns with CWE-835 which describes the use of a loop with no exit conditions leading to infinite looping and potential system hangs. It also relates to CWE-400 concerning uncontrolled resource consumption where internal kernel structures consume all available tags without proper fallback mechanisms. In terms of MITRE ATT&CK, while this is not an exploitable attack vector for malicious actors in the traditional sense, it represents a reliability failure that could be leveraged in availability-focused attacks if triggered repeatedly by specific workload patterns or stress conditions against storage subsystems.
The resolution involves modifying scsi_eh_lock_door to pass the BLK_MQ_REQ_NOWAIT flag when calling scsi_alloc_request. This change ensures that tag allocation fails immediately rather than blocking indefinitely when no tags are available. Since locking the door is considered a best-effort operation within the error handling context, allowing this step to fail silently breaks the circular dependency chain. The error handler can then proceed to finish restarting the queues without waiting for unavailable resources. Once the host transitions back to SHOST_RUNNING and scsi_run_host_queues executes, pending commands are dispatched normally using available tags, restoring full I/O functionality. This fix prioritizes system stability over strict adherence to door-locking procedures during recovery, ensuring that storage subsystems remain responsive even under heavy load or error conditions.