CVE-2024-26627

What it actually does

The flaw causes scsi_eh_wakeup() to invoke scsi_host_busy() under the host lock on every call during error recovery; with N hardware queues and M queue depth this results in serialized O(N*M) iterations under the lock, leading to hard lockup when all tags are in-flight.

Why it matters to the business

High-performance storage systems using many hardware queues can become unresponsive or crash during SCSI error recovery, causing extended downtime and potential data-path disruption on affected Linux kernels.

How an attack unfolds

An error condition (device failure, timeout, or deliberate fault injection) triggers SCSI error handling while a large number of requests remain in flight across multiple queues; repeated scsi_host_busy() calls under the host lock then consume excessive CPU time and can induce a hard lockup on the acquiring CPU.

How to fix it

Update the Linux kernel to a version containing commit f5944853f7a961fedc1227dc8f60393f8936d37c or later; rebuild and reboot all affected hosts. Where immediate patching is impossible, reduce hardware queue count or queue depth as a temporary mitigation.

How to confirm the fix worked

Confirm the running kernel contains commit f5944853f7a961fedc1227dc8f60393f8936d37c via 'uname -r' and kernel source inspection, then reproduce a full-queue error-recovery scenario and verify that scsi_host_busy() is no longer called under the host lock.

Typical attack path

1. Trigger a SCSI device or transport error while the queue is fully occupied
2. Cause scsi_eh_wakeup() to be invoked for each completing request
3. Force repeated acquisition of the host lock inside scsi_host_busy() loops
4. Exhaust CPU time on the lock holder until the watchdog fires a hard lockup

How to detect it

Search kernel logs and dmesg for hard LOCKUP or NMI watchdog messages that mention scsi_eh_wakeup or scsi_host_busy; correlate with storage device error or timeout events on systems known to have many hardware queues.

What your security team should do

• Prioritize kernel updates on systems with >16 hardware queues or queue depths >256
• Add the fixed commit ID to internal kernel build pipelines and CI gates
• Monitor for hard-lockup watchdog messages referencing scsi_host_busy during storage error events
• Test error-recovery paths in staging environments that mirror production queue configurations