A critical bug was found and fixed in the Linux kernel’s UFS (Universal Flash Storage) core related to runtime power management. This post breaks down the CVE-2024-53053 vulnerability, explaining how a deadlock could occur in the asynchronous RTC (Real Time Clock) update mechanism. We’ll look at what caused the problem, how it was fixed, and what it means for system administrators and kernel developers.

What is SCSI UFS in Linux?

SCSI (Small Computer System Interface) is a set of standards for connecting and transferring data between computers and peripheral devices. UFS is a high-performance storage specification commonly used in smartphones and embedded systems. Linux includes a SCSI subsystem to manage UFS devices, and it uses a component called ufshcd to do the heavy lifting.

How Did the Vulnerability Happen?

The Linux kernel’s UFS SCSI core includes a function ufshcd_rtc_work for RTC updates. At the end of its work, ufshcd_rtc_work calls ufshcd_rpm_put_sync() to potentially suspend the hardware device if not used.

But, there’s a catch

- If the hardware’s power management usage count is already zero when ufshcd_rpm_put_sync() is called,

Here’s a simplified version of the flow

// In ufshcd_core.c

void ufshcd_rtc_work(struct work_struct *work)
{
    // ... RTC update operations ...

    // This might deadlock if usage_count == !
    ufshcd_rpm_put_sync(hba);
}

- ufshcd_rpm_put_sync blocks until the device is actually in low power, which leads to trouble if the suspend path is waiting for the same work item.

The Fix: Using Non-blocking Release

The fix replaces ufshcd_rpm_put_sync() with ufshcd_rpm_put() in the work context. This avoids waiting in a context where it could deadlock.

Before

ufshcd_rpm_put_sync(hba);

After

ufshcd_rpm_put(hba);

*Why does this work?*

- The non-sync version (ufshcd_rpm_put) just decreases the usage count and schedules suspend *asynchronously*, so it doesn’t get trapped waiting on itself.

Official Patch Commit

- Upstream commit on kernel.org

How Could Someone Exploit This?

While this is not a remote code execution or privilege escalation bug, it could potentially allow a local user or process to trigger an intentional kernel deadlock by timing UFS access and RTC update routines. This would lock up kernel threads, possibly degrading device function or causing a denial-of-service (DoS) state.


## How to Fix / Mitigate

Update to a Linux kernel release with this patch merged (check your vendor’s changelogs).

- If you build your own kernel, ensure you’ve cherry-picked or merged commit 75dcfc3c5b4bc4cf6df356adc13518d9e1025cee.

Make sure your devices using UFS (particularly mobile or embedded) are running patched kernels.

- Monitor for unresponsive I/O or deadlocks during suspend/resume cycles as a symptom.

References

- Linux Kernel Patch Commit (kernel.org)
- CVE Record for CVE-2024-53053 (MITRE) (record may update as details are publicized)
- Kernel SCSI UFS driver source

Conclusion

CVE-2024-53053 is a subtle but serious issue in the Linux kernel’s SCSI UFS support, capable of deadlocking the kernel during routine RTC updates. The simple switch from a synchronous to an asynchronous power management call (ufshcd_rpm_put_sync → ufshcd_rpm_put) highlights how minor code differences can have critical stability implications. If you or your organization use Linux on hardware with UFS storage, update your kernel and stay safe.


*This advisory is exclusive and written to make kernel security easier to understand for all audiences. For questions or corrections, drop a comment below!*

Timeline

Published on: 11/19/2024 18:15:25 UTC
Last modified on: 11/22/2024 17:09:28 UTC