CVE-2024-53053

What it actually does

A deadlock occurs in the Linux kernel UFS SCSI core when ufshcd_rtc_work invokes ufshcd_rpm_put_sync() with a zero usage_count, allowing the runtime suspend callback to block while waiting to flush the same work item.

Why it matters to the business

Systems using affected UFS storage may experience kernel-level hangs or unresponsiveness during power management events, disrupting operations and requiring reboots with potential data loss risk.

How an attack unfolds

An attacker with local access triggers the RTC work path under low PM usage conditions to force the synchronous put into the suspend callback, creating the deadlock; listed threat actors have targeted similar Linux kernel resource issues in espionage and financially motivated campaigns.

How to fix it

Apply the upstream fix by replacing ufshcd_rpm_put_sync() with ufshcd_rpm_put() in the RTC work handler; update to a kernel containing the resolution for CVE-2024-53053.

How to confirm the fix worked

Confirm the patched code path uses the asynchronous put variant and test runtime suspend/resume cycles with RTC updates to ensure no deadlock occurs.

Typical attack path

1. Gain local execution context on a Linux system with UFS storage
2. Manipulate runtime PM state so usage_count reaches zero
3. Trigger ufshcd_rtc_work execution
4. Observe deadlock when suspend callback waits on work flush

How to detect it

Review kernel logs for ufshcd_rtc_work and runtime PM deadlock indicators; correlate with workqueue flush waits and UFS power events; consider threat actor patterns around Linux kernel resource vulnerabilities.

What your security team should do

• Prioritize kernel updates on systems with UFS controllers due to the race condition nature
• Monitor for kernel deadlock reports in dmesg or systemd logs related to ufshcd
• Test power management behavior after patching in staging environments