CVE-2021-47188

What it actually does

Failure to clear lrbp->cmd in the UFS SCSI abort handler leaves a stale command pointer, so a later ufshcd_queuecommand call hits WARN_ON(lrbp->cmd) during error recovery paths.

Why it matters to the business

Kernel warnings and potential storage command handling instability on UFS devices can interrupt I/O operations and reduce system reliability under error conditions.

How an attack unfolds

A local process triggers SCSI error handling involving device aborts on UFS hardware; the missing pointer clear in the abort path allows the race to surface when queuecommand is subsequently invoked.

How to fix it

Apply the upstream fix that clears lrbp->cmd inside the abort handler; update to a Linux kernel version containing the scsi: ufs: core: Improve SCSI abort handling change.

How to confirm the fix worked

Inspect ufshcd.c around the abort handler for the lrbp->cmd = NULL assignment; reproduce SCSI EH abort paths and confirm absence of the WARN_ON in dmesg.

Typical attack path

1. Obtain local user access on an affected Linux system
2. Perform or induce I/O operations against UFS storage that require SCSI error recovery
3. Force abort sequences so the incomplete handler leaves lrbp->cmd set
4. Trigger follow-on queuecommand calls to hit the warning and disrupt storage handling

How to detect it

Search kernel logs for the exact WARN_ON stack trace containing ufshcd_queuecommand, scsi_eh_test_devices, and scsi_error_handler; examine UFS abort-related call traces for signs of prior trigger.

• ufshcd_queuecommand+0x468/0x65c
• WARNING: CPU:.*PID:.*at drivers/scsi/ufs/ufshcd.c:2737
• WARN_ON(lrbp->cmd)

What your security team should do

• Prioritize kernel updates on systems exposing UFS storage
• Add kernel log monitoring for ufshcd_queuecommand warnings
• Test storage error-recovery paths after patching