CVE-2026-43415

What it actually does

This flaw is a race condition in the Linux kernel UFS storage driver suspend path. During UFS suspend, delayed RTC work can remain active while vendor-specific suspend operations are changing clock or power state. On systems where UFS clock gating capability is not supported, the RTC update path can access the UFS device while suspend-related clock operations are in progress, triggering an asynchronous SError on affected ARM64-style platforms. The practical technical result is a kernel panic and system crash, impacting availability rather than confidentiality or integrity.

Why it matters to the business

Affected systems can crash during storage power-management transitions, causing service interruption, device reboot, workload disruption, and possible data unavailability. Because exploitation requires local privileges and a timing-dependent race, broad remote compromise is unlikely; however, systems using UFS-backed storage in mobile, embedded, edge, appliance, or ARM64 server environments may experience operational instability if an attacker or local workload can repeatedly trigger suspend/resume behavior. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so remediation should be prioritized based on exposure to untrusted local users and operational sensitivity of affected devices.

How an attack unfolds

An attacker first needs local access with the ability to run code or otherwise influence power-management activity on an affected Linux system using the vulnerable UFS driver path. The attacker attempts to create repeated suspend or runtime power-management transitions while UFS RTC delayed work is eligible to run. If the timing aligns, the delayed RTC work executes while the UFS suspend routine is performing clock or vendor-specific power-state changes. On affected hardware and configurations, the UFS command path then encounters an asynchronous SError, causing the kernel to panic. Successful exploitation results in denial of service through a system crash or reboot; there is no indication from the vulnerability details that it enables privilege escalation, data theft, or code execution.

How to fix it

Apply a Linux kernel update that includes the upstream fix moving cancel_delayed_work_sync() before the UFS vendor suspend transition, ensuring UFS RTC delayed work is cancelled or completed before suspend clock/power changes occur. If vendor or distribution packages are used, upgrade to the first kernel build from that vendor that references this CVE or the corresponding UFS suspend/RTC work race fix. No exact fixed package versions were provided in the input, so use distribution advisories, stable kernel changelogs, or device vendor firmware/kernel releases to identify the corrected build. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or minimizing suspend/runtime power-management transitions where operationally acceptable, and monitoring for repeated kernel panics involving the UFS driver.

How to confirm the fix worked

Confirm the running kernel version includes the UFS fix by checking vendor advisories, kernel package changelogs, or source patches for the change that cancels UFS RTC delayed work before ufshcd_vops_suspend() PRE_CHANGE. Validate that systems using UFS storage have been rebooted into the patched kernel, not merely had the package installed. Review kernel logs after suspend/resume testing to ensure there are no new asynchronous SError panics or UFS RTC work traces. For source-based validation, inspect the UFS host controller suspend path and verify cancel_delayed_work_sync() for the RTC work occurs before the relevant ufshcd_vops_suspend() transition rather than after it.

Typical attack path

1. Obtain local low-privileged access to an affected Linux system using UFS storage.
2. Identify or infer that the system uses the vulnerable UFS host controller driver path and supports suspend or runtime power-management transitions.
3. Repeatedly trigger or influence suspend/resume or runtime power-management events while creating timing pressure on UFS activity.
4. Win the race where ufshcd_rtc_work() runs while ufshcd_vops_suspend() is changing clock or power state.
5. Cause an asynchronous SError in the UFS path, leading to a kernel panic and denial of service.

How to detect it

Look for evidence of kernel panics or unexpected reboots associated with the UFS driver suspend and RTC work paths. Relevant sources include kernel ring buffer logs, persistent journal logs, serial console captures, pstore/ramoops records, crash dump systems, watchdog reset logs, and endpoint telemetry that records system panic reasons. Search for asynchronous SError panic messages and call traces containing ufshcd_rtc_work(), ufshcd_vops_suspend(), ufshcd_update_rtc(), ufshcd_issue_dev_cmd(), or UFS MCQ cleanup functions. Because exploitation is timing-dependent and local, logs may not show a clear attacker command; correlate matching crashes with local user sessions, power-management requests, suspend/resume events, container or app activity, and repeated access to sysfs power controls. Absence of these logs does not prove non-exploitation if crash logs are not persisted across reboot.

• Kernel panic - not syncing: Asynchronous SError Interrupt
• arm64_serror_panic
• do_serror
• ufshcd_rtc_work
• ufshcd_update_rtc
• ufshcd_vops_suspend
• ufshcd_issue_dev_cmd
• ufshcd_exec_dev_cmd
• ufshcd_query_attr
• ufshcd_mcq_sq_stop
• ufshcd_mcq_sq_cleanup
• ufshcd_clear_cmd
• process_scheduled_works
• worker_thread
• /sys/power/state
• /sys/devices/*/power/control

What your security team should do

• Inventory Linux systems, appliances, embedded devices, mobile platforms, and ARM64 systems that use UFS storage and kernel builds containing the vulnerable UFS driver code.
• Prioritize patching systems where untrusted local users, containers, kiosk users, mobile apps, or third-party workloads can influence suspend/resume or runtime power-management behavior.
• Upgrade to a vendor-supported kernel or firmware release containing the UFS RTC work suspend race fix, then reboot into the fixed kernel.
• Where patching is delayed, restrict local code execution and reduce access to power-management interfaces such as suspend, resume, and runtime PM controls.
• Monitor kernel logs, crash dumps, and watchdog reboot records for UFS-related asynchronous SError panics, especially after suspend/resume events.
• Treat repeated matching panics on exposed systems as potential denial-of-service attempts, while also considering benign hardware or power-management instability as a possible cause.