CVE-2026-93781 — scsi: core: Do not block on tag allocation in scsi_eh_lock_door()

Affected: Linux

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 b…

Most recent entries from all

CVE-2026-93781 — scsi: core: Do not block on tag allocation in scsi_eh_lock_door()