CVE-2024-26842

What it actually does

Out-of-bounds left shift in ufshcd_clear_cmd() when task_tag >= 32 under MCQ mode on 32-bit unsigned int platforms, producing undefined behavior that manifests as kernel BRK exceptions and panics during device command handling and error recovery paths.

Why it matters to the business

Unexpected kernel crashes on Linux systems using UFS storage controllers in multi-command-queue mode can interrupt storage I/O, trigger system reboots, and reduce availability for servers, mobile devices, and embedded platforms; the large number of downstream kernel users amplifies exposure.

How an attack unfolds

An attacker with the ability to influence UFS command submission (via local processes or crafted storage workloads) forces task_tag values >= 32 during device initialization or error handling; the resulting invalid shift triggers a debug monitor exception that halts the kernel, as observed in the ufshcd_err_handler workqueue path.

How to fix it

Update the Linux kernel to a version containing commit 7ac9e18f5d66087cd22751c5c5bf0090eb0038fe; rebuild and deploy the fixed kernel across all affected distributions and embedded images; prioritize systems that enable UFS MCQ mode.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or a backport that masks the shift with an appropriate type (e.g., 1UL); exercise UFS probe, command submission, and error-handler paths under load while monitoring for BRK or shift-related exceptions.

Typical attack path

1. Obtain local execution context on a system with UFS/MCQ-enabled storage
2. Trigger UFS device command paths that allocate task tags >= 32
3. Induce error recovery or probe operations that call ufshcd_clear_cmd()
4. Cause kernel BRK/panic via the out-of-bounds shift

How to detect it

Search kernel logs and crash dumps for ufshcd_clear_cmd call sites, BRK handler entries, and workqueue traces involving ufshcd_err_handler or ufshcd_wait_for_dev_cmd; correlate with UFS device initialization failures.

What your security team should do

• Apply the fixed kernel commit immediately on production UFS/MCQ systems
• Monitor kernel logs for ufshcd_clear_cmd and BRK exceptions until patched
• Test storage error-recovery paths in staging environments after upgrade
• Track downstream distribution advisories for packaged kernel updates