CVE-2026-93276 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator
devm_regulator_get_exclusive() initialises the regulator with enable_count = 1, requiring the consumer to disable it before release.
The devm disable action was previously only registered when the caller explicitly requested enable, so when the regulator was left in its initial enabled state without an explicit enable call, the cleanup path skipped decrementing enable_count, triggering a WARN_ON during regulator release on device removal.
Fix this by always registering the devm disable action based on the actual enabled state via regulator_is_enabled(), regardless of whether the caller requested an explicit enable. This covers both the explicitly enabled case and the initial state set by devm_regulator_get_exclusive().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in the Linux kernel's Renesas R-Car Gen3 USB2 PHY driver stems from a mismatch between regulator initialization semantics and device resource management cleanup procedures. Specifically, the function devm_regulator_get_exclusive is designed to acquire an exclusive handle to a power supply regulator while ensuring that the consumer of this resource assumes responsibility for its lifecycle state. A critical aspect of this API is that it initializes the regulator with an enable_count set to one, effectively marking the regulator as enabled from the moment of acquisition. This design choice mandates that any code path utilizing this function must ensure the regulator is disabled prior to release to maintain system stability and prevent resource leaks or hardware state inconsistencies.
The core technical flaw lies in the conditional registration of the device-managed disable action within the driver's probe routine. Previously, the logic for registering a cleanup handler to disable the regulator was gated behind a check determining whether the caller explicitly requested an enable operation. This approach failed to account for the default enabled state imposed by devm_regulator_get_exclusive itself. Consequently, if the hardware configuration or device tree did not require an explicit enable call during initialization, the driver would skip registering the necessary cleanup action. As a result, when the device was removed from the system, the regulator release routine attempted to decrement the enable_count without having previously disabled the regulator, leading to a WARN_ON condition being triggered in the kernel log due to state inconsistency.
From an operational perspective, this vulnerability primarily manifests as a kernel warning during device removal or driver unbinding scenarios rather than immediate functional failure under normal operation. However, such warnings indicate underlying resource management defects that can lead to unpredictable behavior over time. In more severe cases, failing to properly disable regulators upon release can result in power rail instability, increased power consumption due to the regulator remaining active when it should be off, or potential conflicts with other drivers attempting to access the same hardware resources. The issue highlights a common class of bugs where assumptions about caller intent override strict adherence to resource management contracts defined by kernel APIs.
This flaw aligns with CWE-401, which describes missing release of memory after successful allocation, although in this context it extends to power supply state management rather than just memory. It also relates to improper cleanup procedures that fail to reverse actions taken during initialization, a pattern often seen in systems programming errors where the symmetry between setup and teardown is broken. The ATT&CK framework does not directly map kernel driver bugs like this to specific attack techniques as they are typically unintentional defects rather than exploitable vulnerabilities for remote code execution or privilege escalation. However, such issues can contribute to system instability which might be leveraged in denial-of-service scenarios if an attacker can trigger repeated device removal and insertion cycles.
The resolution involves modifying the driver logic to unconditionally register the devm disable action based on the actual enabled state of the regulator as determined by regulator_is_enabled(). This ensures that regardless of whether the caller explicitly requested an enable operation, the cleanup path will correctly handle the regulator's state during release. By aligning the registration of the cleanup handler with the true runtime state rather than just initialization intent, the driver now guarantees that the enable_count is properly decremented and the regulator is disabled before being released back to the system. This fix restores compliance with the devm_regulator_get_exclusive contract and prevents the WARN_ON condition during device teardown.
To mitigate similar issues in other kernel drivers, developers should rigorously audit all uses of resource-managed APIs that imply state changes or ownership transfer. It is essential to ensure that cleanup handlers are registered based on actual runtime states rather than conditional logic derived from initialization parameters alone. Regular static analysis and code reviews focusing on the symmetry between acquisition and release functions can help identify these discrepancies early in the development cycle. Additionally, leveraging kernel testing frameworks that simulate device hot-plug events can expose such resource management flaws before they reach production environments.