CVE-2026-99034 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-sprd: disable runtime PM on remove
sdhci_sprd_probe() enables runtime PM, while sdhci_sprd_remove() does not perform the corresponding runtime PM cleanup.
The probe failure path disables runtime PM before disabling the clocks, but the normal remove path directly disables clocks that are also managed by the runtime PM callbacks. If the device is runtime suspended, those clocks may already be disabled.
Resume the device before removal, disable runtime PM and drop the temporary runtime PM reference before disabling the clocks.
This issue was found by manual code inspection.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in the Linux kernel's Secure Digital Host Controller Interface (SDHCI) driver for Spreadtrum platforms represents a critical resource management flaw within the power management subsystem. Specifically, this issue resides in the sdhci_sprd module where there is an asymmetry between device initialization and removal procedures regarding runtime Power Management (PM). During the probe phase, which occurs when the system detects or initializes hardware devices, the driver correctly enables runtime PM to allow for dynamic power savings based on device activity. However, during the remove phase, triggered when a device is unplugged or unloaded from the kernel, the corresponding cleanup logic fails to disable runtime PM before attempting to manage hardware clocks. This oversight creates a state inconsistency where the system believes the device's power management framework is active while the underlying clock infrastructure has been forcibly disabled by the removal routine.
The technical root cause lies in the sequence of operations during the driver's remove function. When sdhci_sprd_remove executes, it proceeds directly to disabling hardware clocks without first ensuring that the runtime PM subsystem is deactivated or suspended. If the device happens to be in a runtime-suspended state at the moment of removal, its associated clocks are already disabled by the power management callbacks. Consequently, attempting to disable these same clocks again can lead to undefined behavior, potential kernel panics, or hardware instability because the driver attempts to manipulate resources that are no longer under its direct control due to the active but improperly terminated runtime PM state. This scenario highlights a failure in adhering to proper device lifecycle management protocols where resource acquisition must be strictly mirrored by corresponding release operations in reverse order of complexity and dependency.
From an operational impact perspective, this vulnerability can lead to system instability or crashes when devices are dynamically removed from the system while they were previously suspended for power saving purposes. In embedded systems utilizing Spreadtrum chipsets, such as mobile phones or IoT devices, frequent hot-plugging or driver reloading could trigger these errors. The lack of proper state synchronization means that subsequent attempts to access the device might fail unpredictably, potentially causing data corruption in storage operations if an SD card is involved, or simply resulting in a kernel oops that requires a system reboot. This undermines the reliability and robustness expected from embedded Linux environments where power efficiency and hardware stability are paramount for user experience and battery life.
To mitigate this vulnerability, the driver implementation must be updated to ensure that runtime PM is explicitly disabled before any clock operations occur during device removal. The correct sequence involves first resuming the device if it is suspended, thereby re-enabling clocks under controlled conditions; then disabling runtime PM to prevent further automatic power state changes by the kernel framework; dropping any temporary references held by the driver; and finally proceeding with the standard clock disablement routine. This ensures that all hardware resources are in a known, stable state before being released back to the system. Developers should also implement rigorous code inspection practices similar to those used for discovery of this bug to catch such asymmetries early in the development cycle.
This flaw aligns with CWE-401, which describes missing release of memory or other resources after allocation, specifically applied here as a failure to properly release power management state and associated hardware control rights. Furthermore, it relates to ATT&CK technique T1562, Impair Defenses, particularly in the context of disrupting system availability through resource mismanagement that leads to instability. Addressing this issue requires strict adherence to kernel driver best practices where every enablement call must have a corresponding disablement counterpart executed in the reverse order of dependency during teardown sequences.