CVE-2026-43275: Linux Kernel UFS Race Condition Flaw

CVE-2026-43275 Overview

CVE-2026-43275 is a race condition vulnerability in the Linux kernel's Universal Flash Storage (UFS) core driver. The flaw resides in the SCSI UFS subsystem (scsi: ufs: core) and triggers when the runtime power management (RPM) level is set to UFS_PM_LVL_0. Under this configuration, the UFS core driver previously bypassed flushing exception event handling work during suspend. The driver could then attempt to access the host controller after the system entered a deep power-down state. The resulting illegal hardware access caused a system crash. Upstream maintainers resolved the issue by explicitly flushing pending exception work and disabling auto background operations (BKOPs) before the suspend callback proceeds.

Critical Impact

A race condition between exception event handling and the suspend path can drive the kernel to access powered-down UFS hardware, producing a system crash and denial of service on affected Linux systems.

Affected Products

• Linux kernel (mainline) containing the SCSI UFS core driver
• Stable kernel branches receiving backports referenced in the kernel.org commit set
• Embedded and mobile Linux distributions using UFS storage with UFS_PM_LVL_0 runtime power management

Discovery Timeline

• 2026-05-06 - CVE-2026-43275 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43275

Vulnerability Analysis

The vulnerability exists in the UFS core driver's suspend handling logic. When the runtime power management level is UFS_PM_LVL_0, both the device power mode and the UFS link state remain active. The original code path treated this as a case where exception event handling work did not need to be flushed before suspending.

This assumption created a race window. Pending exception handler jobs could continue executing while the suspend sequence brought the host controller into a deep power-down state. When the exception handler then issued register accesses to a controller that was no longer powered, the kernel encountered illegal hardware access and crashed. The defect is a synchronization bug between asynchronous workqueue execution and the platform power management state machine.

Root Cause

The root cause is a missing work flush in the UFS suspend callback when rpm_lvl == UFS_PM_LVL_0. Auto BKOPs were also left enabled across the transition. Without flushing pending exception work and disabling auto BKOPs, the driver permitted exception handling to overlap with the controller's power-down sequence.

Attack Vector

The condition is triggered through normal power management transitions rather than direct attacker input. A local workload that induces UFS exception events while the system enters runtime suspend at PM level zero can reproduce the crash. The fix flushes the exception event handler and disables auto BKOPs before suspend proceeds, ensuring all pending tasks complete before hardware is powered down. See the Kernel Git Commit - 5d186731 and Kernel Git Commit - f8ef4418 for the upstream patches.

// No verified exploit code is published for this issue.
// The fix flushes exception event work and disables auto BKOPs
// before the UFS suspend callback proceeds when RPM level is UFS_PM_LVL_0.

Detection Methods for CVE-2026-43275

Indicators of Compromise

• Kernel oops or panic traces referencing UFS host controller register access during suspend or resume
• Unexpected system crashes correlated with runtime power management transitions on devices using UFS storage
• Log entries from the ufshcd driver indicating exception event handling immediately preceding a crash

Detection Strategies

• Inventory running kernels and compare against the fixed commits referenced on kernel.org to identify unpatched builds
• Review crash dumps and dmesg output for UFS exception handler functions on the call stack at the time of failure
• Correlate device runtime PM configuration (rpm_lvl) with crash frequency to confirm exposure to the vulnerable path

Monitoring Recommendations

• Centralize kernel logs and crash telemetry from Linux endpoints and embedded devices that rely on UFS storage
• Alert on repeated kernel panics that include UFS or ufshcd symbols in the backtrace
• Track kernel version and patch level across the fleet to validate that backports of the fix have landed

How to Mitigate CVE-2026-43275

Immediate Actions Required

• Apply the upstream Linux kernel patches that flush exception event handling work and disable auto BKOPs before UFS suspend
• Update to a stable kernel release that includes the commits listed on kernel.org for this CVE
• Reboot affected systems after patching to ensure the fixed driver is loaded

Patch Information

Fixes are available across multiple stable branches. Reference commits include Kernel Git Commit - 5d186731, Kernel Git Commit - 78d8e2d6, Kernel Git Commit - aa8d68d9, Kernel Git Commit - aac2fee7, Kernel Git Commit - ab71c146, Kernel Git Commit - d5c3a1a1, and Kernel Git Commit - f8ef4418. Distribution vendors integrate these into their respective kernel updates.

Workarounds

• Where patching is not immediately possible, avoid configuring UFS runtime power management at level zero (UFS_PM_LVL_0) on affected systems
• Validate device tree and platform configurations to confirm the runtime PM level used by ufshcd before deployment
• Stage kernel updates through device test fleets to confirm the fix resolves crashes under suspend and resume workloads

# Check the running kernel version on a Linux host
uname -r

# Inspect UFS runtime power management level (path varies by platform)
cat /sys/bus/platform/drivers/ufshcd/*/rpm_lvl 2>/dev/null

# Review recent kernel messages for UFS-related crashes
dmesg | grep -iE 'ufs|ufshcd'