CVE-2026-43275

What it actually does

This is a Linux kernel race condition in the UFS storage core driver during system suspend. When runtime power management is configured at UFS_PM_LVL_0, the device and link remain active, and older kernel code could skip flushing pending UFS exception-event handling work before the platform entered a deeper power-down state. If the queued exception handler later attempted to access the UFS host controller after it was no longer safely accessible, the kernel could crash. The practical technical impact is local denial of service through a kernel panic or system crash; the issue does not provide confidentiality or integrity impact based on the published details.

Why it matters to the business

Affected Linux systems using UFS storage may crash during suspend or power-state transitions, causing service interruption, device instability, data-loss risk from abrupt shutdowns, and operational disruption for fleets that rely on suspend/resume behavior such as mobile, embedded, edge, workstation, and appliance deployments. The issue is not listed in CISA KEV, has no known exploit maturity, and has a very low EPSS score, so it is generally a reliability and availability risk rather than an active widespread exploitation concern.

How an attack unfolds

An attacker would need local access with the ability to influence power-management behavior or trigger conditions that create pending UFS exception-handling work while the system is entering suspend. The attacker attempts to time suspend or runtime power-state transitions so that exception-event work remains queued when the UFS driver proceeds into the suspend path with runtime power management level zero. On vulnerable kernels, that work may not be flushed before the system enters a deep power-down state. If the queued handler runs after the host controller is no longer safely accessible, the kernel may perform an illegal hardware access and crash, causing a denial-of-service condition. Exploitation is high-complexity and timing-dependent, and there is no indication from the provided data that this is being used in ransomware or known campaigns.

How to fix it

Update to a Linux kernel build that contains the UFS core fix which explicitly flushes exception-event handling work and disables auto BKOPs before the suspend callback proceeds when runtime power management level is UFS_PM_LVL_0. Because exact fixed package versions were not provided, use the latest kernel updates from the relevant Linux distribution, device vendor, or kernel branch maintainer and confirm the vendor advisory states this UFS suspend race fix is included. Where immediate patching is not possible, reduce exposure by disabling or limiting suspend/deep power-state transitions on affected UFS-based systems, avoiding UFS_PM_LVL_0 configurations if an alternative supported runtime power management level is available, and applying vendor-recommended power-management mitigations. Treat mitigations as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel version and vendor package changelog include the UFS core change that flushes exception-event handling work during suspend at UFS_PM_LVL_0. Validate exposure by checking whether systems use UFS storage and whether suspend/runtime power management is enabled. After patching, perform controlled suspend/resume or runtime power-management testing on representative hardware while monitoring kernel logs for UFS errors, kernel oopses, panics, or blocked workqueue activity. Confirm no recurring crashes occur during suspend/resume cycles and that crash dumps no longer show stack traces involving UFS exception-event handling during power-down.

Typical attack path

1. Obtain local code execution or user-level access on a Linux system using an affected UFS storage configuration.
2. Identify or influence suspend, resume, or runtime power-management activity involving the UFS controller.
3. Generate or wait for UFS exception-event handling work to be queued near the suspend transition.
4. Race the suspend path so the system enters a deep power-down state before exception work has completed.
5. Trigger the stale exception handler to access the UFS host controller after it is unsafe to do so.
6. Cause a kernel crash or panic, resulting in local denial of service.

How to detect it

To determine whether this was already triggered, review kernel logs, system journals, pstore/ramoops records, crash dumps, and hardware watchdog reset logs for crashes or unexpected reboots occurring during suspend, resume, or runtime power-management transitions. Focus on kernel oops or panic stack traces involving the UFS core driver, UFS host controller access, exception-event handling, suspend callbacks, workqueues, or auto BKOP handling. Correlate crashes with local user activity, automated suspend policies, power-management daemons, lid-close events, mobile/embedded sleep cycles, or test scripts that repeatedly suspend and resume the system. Because the flaw causes denial of service rather than persistent compromise, there may be no traditional malware artifact; repeated timing-correlated kernel panics around UFS suspend paths are the strongest evidence.

• ufshcd_exception_event_handler
• ufshcd_suspend
• ufshcd_wl_suspend
• UFS_PM_LVL_0
• auto BKOP
• BKOP
• scsi: ufs
• ufs: exception event
• ufshcd
• kernel panic
• Oops:
• BUG: unable to handle kernel
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• PM: suspend entry
• PM: suspend exit
• systemd-sleep
• pstore
• ramoops

What your security team should do

• Prioritize patching systems that use UFS storage and rely on suspend/resume or aggressive power-management behavior, especially embedded, mobile, edge, workstation, and appliance fleets.
• Obtain the fixed kernel from the operating system, device, or appliance vendor; if no fixed version is published, track vendor advisories and kernel stable updates until the fix is available.
• Temporarily disable suspend or adjust UFS runtime power-management settings on high-availability systems where crashes would cause operational impact.
• Monitor kernel logs, pstore, crash dumps, and systemd journal entries for UFS-related crashes during suspend or resume.
• Because this is not KEV-listed, not linked to ransomware, and has very low EPSS, handle it through risk-based kernel maintenance unless affected systems are experiencing suspend-related instability.
• Include this issue in regression testing for suspend/resume behavior on hardware platforms using UFS storage.