CVE-2024-53067

What it actually does

The vulnerability is a race condition in the Linux kernel UFS driver where the RTC update workqueue item is scheduled before runtime power management initialization completes, leading to an invalid call to pm_runtime_get_if_active from within a spinlock context and a subsequent kernel oops/crash.

Why it matters to the business

Linux systems using UFS storage may experience unexpected kernel crashes and reboots during boot or device initialization, causing downtime and potential data access interruptions; low exploitability and no known active campaigns reduce immediate risk but still require patching for stability.

How an attack unfolds

An attacker with local access triggers or waits for the ufshcd_rtc_work workqueue item to execute before the UFS runtime PM is fully initialized; this causes the work handler to invoke pm_runtime_get_if_active without proper locking or initialization, resulting in the observed oops. No public exploits or named threat actors have been tied specifically to this issue despite general Linux kernel activity mentions.

How to fix it

Update the Linux kernel to a version containing commit 6e34b9d7caa5a4c831b74bdfed5ef86fa0c03316 or later; ensure the RTC update work is only started after runtime power management initialization completes. Reboot after applying the kernel update.

How to confirm the fix worked

Verify the running kernel contains commit 6e34b9d7caa5a4c831b74bdfed5ef86fa0c03316 via 'uname -r' and kernel source inspection; confirm no crash occurs on UFS devices during boot and that ufshcd_rtc_work scheduling happens post-PM init.

Typical attack path

1. Obtain local code execution or shell access on a vulnerable Linux system with UFS hardware
2. Trigger or accelerate the events workqueue that schedules ufshcd_rtc_work
3. Execute before runtime PM initialization finishes in the UFS driver
4. Induce the kernel oops via the unsafe pm_runtime_get_if_active call under spinlock

How to detect it

Search kernel logs and dmesg for 'ufshcd_rtc_work', 'pm_runtime_get_if_active', and 'Oops: 0000000096000006' entries around boot or UFS device events; review workqueue activity preceding the crash.

What your security team should do

• Prioritize kernel updates on all systems using UFS storage within standard patch cycles given low EPSS and no KEV listing
• Monitor kernel logs for 'ufshcd_rtc_work' related oops entries as an indicator of exposure
• Test the fixed kernel in staging environments with UFS hardware before broad deployment