CVE-2024-41053

What it actually does

Race condition between ufshcd_abort_one and UFS completion ISR nullifies rq->mq_hctx, causing NULL pointer dereference in blk_mq_unique_tag during error handler execution.

Why it matters to the business

Kernel crashes on Linux systems using UFS storage during command error recovery can cause unplanned downtime and service disruption; low exploitation likelihood but long public exposure increases risk of future targeting.

How an attack unfolds

An attacker induces UFS command timeouts or errors to activate the error handler while the completion ISR runs concurrently, resulting in a NULL dereference crash when the abort path dereferences the cleared mq_hctx pointer. No named threat actors or ransomware campaigns are associated.

How to fix it

Upgrade to Linux kernel 6.6.41 or later, or apply commit c3111b3cf3889bfa7b73ebff83d7397db9b7e5e0 from stable git trees; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm running kernel contains the referenced commit or version 6.6.41+; reproduce error injection scenarios and verify no NULL dereference occurs in ufshcd_err_handler.

Typical attack path

1. Trigger SCSI command error or timeout on UFS device
2. Race ufshcd_err_handler abort path against completion ISR
3. Cause rq->mq_hctx to be set to NULL by __blk_mq_free_request
4. Invoke blk_mq_unique_tag on nullified pointer leading to panic

How to detect it

Review kernel logs and dmesg for oops/panic traces containing ufshcd_try_to_abort_task, blk_mq_unique_tag, and ufshcd_err_handler; correlate with UFS command timeouts.

What your security team should do

• Apply kernel updates to all systems with UFS controllers within maintenance windows
• Monitor vendor advisories for backported fixes in distribution kernels
• Enable kernel panic logging and watchdog mechanisms for rapid detection of crashes
• Test storage error recovery paths in lab environments before production deployment