GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SCSI core: blocking tag allocation during error recovery can deadlock the EH thread

UnscoredCVE-2026-93781Kernel, userspace & hypervisorcurated

Impact

During SCSI error recovery the host sits in SHOST_RECOVERY while scsi_eh_lock_door() allocates a request with blocking semantics. If every tag is held by commands that scsi_eh_flush_done_q() just requeued, those commands cannot be dispatched until the error handler returns, and the error handler cannot return until a tag frees - a circular wait. The upstream commit says this is a guaranteed deadlock on devices with a single driver tag and that it was reproduced in a real environment. On a GPU node the consequence is availability: the error handler thread hangs and I/O to that host never resumes, so a node whose local or attached storage trips error recovery stops making progress and has to be rebooted rather than drained cleanly. There is no indication in the record that an unprivileged tenant can trigger this on purpose; it depends on a device actually entering error handling.

Who can reach it

Not a remote or tenant-reachable attack path in the record. Requires a SCSI device on the node to enter error recovery while its tags are exhausted; no authentication concept applies.

What to do

Take the stable kernel containing the BLK_MQ_REQ_NOWAIT fix for scsi_eh_lock_door() (five stable branches carry it, linked below). A kernel update means draining the node and rebooting it; there is no runtime mitigation other than avoiding single-tag SCSI devices on the host. No fixed distro version is named in the record.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.