CVE-2026-43415 Overview
CVE-2026-43415 is a race condition in the Linux kernel's Universal Flash Storage (UFS) Small Computer System Interface (SCSI) driver. The flaw resides in the __ufshcd_wl_suspend() function within drivers/ufs/core. The kernel cancels the UFS Real-Time Clock (RTC) delayed work after invoking ufshcd_vops_suspend(hba, pm_op, POST_CHANGE), allowing ufshcd_rtc_work() to execute concurrently with vendor suspend operations that perform clock gating. This concurrent execution triggers an Asynchronous SError Interrupt and a kernel panic on affected ARM64 systems.
Critical Impact
A race condition between UFS RTC work and suspend clock gating produces an Asynchronous SError Interrupt that causes a kernel panic, resulting in denial of service on affected systems.
Affected Products
- Linux kernel UFS SCSI core driver (drivers/ufs/core)
- Systems with UFS host controllers where UFSHCD_CAP_CLK_GATING is not supported
- ARM64 platforms using UFS storage subject to suspend/resume cycles
Discovery Timeline
- 2026-05-08 - CVE-2026-43415 published to NVD
- 2026-05-12 - Last updated in NVD database
Technical Details for CVE-2026-43415
Vulnerability Analysis
The vulnerability is a race condition [CWE-362] in the UFS host controller driver suspend path. In __ufshcd_wl_suspend(), the call to cancel_delayed_work_sync() for the UFS RTC work is placed after ufshcd_vops_suspend(hba, pm_op, POST_CHANGE). This ordering allows ufshcd_rtc_work() to remain runnable while vendor suspend callbacks execute clock gating operations.
When the host controller does not advertise UFSHCD_CAP_CLK_GATING, the guard !hba->clk_gating.active_reqs always evaluates true. As a result, ufshcd_update_rtc() proceeds to call ufshcd_query_attr() and issue a device command through ufshcd_exec_dev_cmd(). If clocks have already been gated by the vendor suspend handler, the subsequent register access in ufshcd_mcq_sq_stop() and ktime_get() paths references hardware that is no longer clocked.
The access to an ungated controller produces an Asynchronous SError Interrupt on ARM64, handled by do_serror() and arm64_serror_panic(), which terminates the kernel with panic().
Root Cause
The root cause is incorrect ordering of teardown operations in the suspend sequence. The RTC delayed worker is not synchronously cancelled before vendor-specific suspend logic disables the clocks that the worker requires. The absence of clock gating capability removes the normal guard that would prevent the RTC update from running during suspend.
Attack Vector
The condition is triggered by normal suspend/resume cycles on affected hardware rather than by a remote attacker. The impact is a kernel panic and system crash, producing a denial of service. No authentication or network access is required; local workload patterns that cause UFS suspend transitions while RTC work is pending are sufficient to expose the race.
The vulnerability is described in prose only. Refer to the upstream commits for the exact code change, including kernel.org commit b17211b and kernel.org commit c387a8f.
Detection Methods for CVE-2026-43415
Indicators of Compromise
- Kernel panic messages containing Asynchronous SError Interrupt followed by a call trace that includes ufshcd_rtc_work, ufshcd_query_attr, ufshcd_exec_dev_cmd, and ufshcd_mcq_sq_stop.
- Unexpected reboots or crashes correlated with system suspend, resume, or low-power transitions on devices using UFS storage.
- dmesg entries showing do_serror and arm64_serror_panic frames near suspend operations.
Detection Strategies
- Audit running kernel versions against the fixed commits listed in the NVD references to identify hosts still exposed to the race.
- Collect and parse crash dumps or pstore console logs for the panic signature involving ufshcd_rtc_work during suspend.
- Track suspend/resume failure telemetry from fleet management tooling on ARM64 devices with UFS storage.
Monitoring Recommendations
- Forward kernel logs from affected ARM64 endpoints to a central log store and alert on SError panic strings.
- Monitor device uptime and unscheduled reboot counts on UFS-based hardware to flag instability that may correspond to this race.
- Track kernel package versions across the environment to confirm patch deployment status.
How to Mitigate CVE-2026-43415
Immediate Actions Required
- Apply the upstream Linux kernel patch that moves cancel_delayed_work_sync() before ufshcd_vops_suspend(hba, pm_op, PRE_CHANGE) in __ufshcd_wl_suspend().
- Update to a kernel version that includes the fix from one of the referenced stable commits and reboot affected hosts.
- Prioritize ARM64 systems that use UFS storage and host controllers without UFSHCD_CAP_CLK_GATING support.
Patch Information
The fix is available in the Linux stable trees. See the upstream commits: commit 2fcc2fc2, commit a6a89441, commit b0bd84c3, commit b17211b5, and commit c387a8f1. The change ensures the UFS RTC work is fully completed or cancelled before vendor suspend logic gates the clocks.
Workarounds
- No supported software workaround exists; patching the kernel is the recommended remediation.
- Where patching is delayed, reduce the frequency of suspend/resume cycles on affected hardware to lower exposure to the race.
- Vendors integrating downstream UFS drivers should backport the ordering fix into their kernel branches before shipping firmware or BSP updates.
# Verify the kernel includes the fix by checking for the patched commit
uname -r
git -C /path/to/linux log --oneline | grep -E "ufshcd_rtc_work|SError in ufshcd_rtc_work"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

