CVE-2021-47622

What it actually does

Race condition in UFS SCSI error handler leads to deadlock when all request tags are allocated, causing ufshcd_err_handler to block indefinitely on blk_mq_get_tag while processing host resets and device commands.

Why it matters to the business

Affected Linux systems using UFS storage may experience prolonged hangs or require manual intervention during storage error recovery, disrupting operations on servers and devices with high tag utilization.

How an attack unfolds

An attacker with local access triggers repeated SCSI errors or I/O failures under load to exhaust tag allocation, forcing the error handler into the deadlock path observed in ufshcd_exec_dev_cmd and ufshcd_verify_dev_init.

How to fix it

Upgrade to fixed kernel versions: Debian 11 to 5.10.92-1 or later, Debian 12/13 to 5.15.15-1 or later, Ubuntu 20.04 LTS variants to the listed 5.4.0 or 5.15.0 backports such as 5.4.0-9.12, 5.4.0-1005.5, 5.15.0-1014.18~20.04.1 and equivalents for azure/aws/bluefield packages.

How to confirm the fix worked

Verify kernel version matches or exceeds the listed fixed packages per distribution, confirm absence of the deadlock trace involving blk_mq_get_tag in ufshcd_err_handler, and test error injection scenarios on UFS hardware.

Typical attack path

1. Trigger conditions that allocate all available request tags
2. Induce SCSI error events requiring host reset
3. Invoke ufshcd_eh_host_reset_handler which queues ufshcd_err_handler work
4. Block on reserved tag allocation inside the error handler leading to deadlock

How to detect it

Review kernel logs and dmesg for traces containing ufshcd_err_handler, blk_mq_get_tag, and schedule calls during UFS reset sequences; correlate with high tag allocation events.

What your security team should do

• Prioritize kernel upgrades on all systems using UFS storage within the next maintenance window
• Monitor for UFS-related error handler activity in kernel logs
• Apply distribution-specific backports if live patching is unavailable