CVE-2024-44953

What it actually does

A deadlock occurs in the UFS core driver when runtime suspend waits for RTC work flush while the RTC work calls ufshcd_rpm_get_sync, resolved by skipping RTC updates unless the RPM state is active.

Why it matters to the business

UFS-based storage systems may experience hangs or reduced availability during power management, impacting data access reliability on affected Linux kernels; the fix is available in a specific stable commit.

How an attack unfolds

Normal kernel runtime power management operations on UFS devices trigger the race between suspend paths and delayed RTC work without requiring attacker privileges or external input.

How to fix it

Apply the upstream fix from commit a4921b76bc9421d3838e167f6a17ea3112d8fe62 which adds the RPM_ACTIVE state check before RTC updates; rebuild and deploy updated kernels for all affected stable branches.

How to confirm the fix worked

Verify the presence of the RPM state guard in ufshcd_rtc_work after patching; confirm no deadlock backtraces appear in dmesg during repeated runtime suspend/resume cycles on UFS hardware.

Typical attack path

1. Initiate runtime PM idle/suspend on UFS SCSI device
2. Allow delayed RTC work to execute concurrently
3. Trigger mutual wait between work flush and rpm_get_sync leading to deadlock

How to detect it

Search kernel logs and traces for worker threads blocked in __flush_work or cancel_delayed_work_sync involving ufshcd_rtc_work and runtime suspend paths.

What your security team should do

• Prioritize kernel upgrades containing a4921b76bc9421d3838e167f6a17ea3112d8fe62 on all UFS-equipped systems
• Test power management workloads in staging before production rollout
• Monitor kernel logs for ufshcd-related worker thread stalls