CVE-2024-46843

What it actually does

The flaw is a missing check on the scsi_host_added flag before calling scsi_remove_host in the UFS core driver when MCQ is enabled; if ufshcd_async_scan fails before scsi_add_host completes, driver removal triggers a kernel panic.

Why it matters to the business

Systems using UFS storage with MCQ support can experience unexpected kernel crashes during driver probe failures or module unload, resulting in unplanned downtime and potential data loss on affected Linux kernels.

How an attack unfolds

An attacker with local access or the ability to influence device initialization can force ufshcd_probe_hba to fail during async scan after MCQ configuration but before SCSI host registration, then trigger driver removal to induce the panic condition.

How to fix it

Apply the fix from commit 2f49e05d6b58d660f035a75ff96b77071b4bd5ed or later stable kernels; set scsi_host_added only after successful scsi_add_host and guard scsi_remove_host with the flag check.

How to confirm the fix worked

Inspect kernel source for the scsi_host_added flag assignment after scsi_add_host and conditional removal logic; boot test UFS devices with MCQ under scan-failure injection to confirm no panic on driver unload.

Typical attack path

1. Configure UFS device with MCQ enabled
2. Cause ufshcd_async_scan to fail before scsi_add_host
3. Initiate ufshcd driver removal
4. Trigger kernel panic due to unconditional SCSI host removal

How to detect it

Review kernel panic logs and oops traces for UFS SCSI host removal sequences; correlate with MCQ configuration messages and failed async scan events around the time of the crash.

• ufshcd_async_scan
• scsi_host_added
• MCQ configuration
• scsi_add_host

What your security team should do

• Prioritize kernel updates containing commit 2f49e05d6b58d660f035a75ff96b77071b4bd5ed on all UFS/MCQ systems
• Monitor for UFS probe failures in system logs
• Test driver unload paths in staging environments before production rollout