CVE-2026-46252 in Linux
Summary
by MITRE • 06/03/2026
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: fix locking in regulator_resolve_supply() error path
If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning:
WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8
as the regulator_list_mutex must be held when calling _regulator_put().
To solve this, simply switch to using regulator_put().
While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that.
While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/03/2026
This vulnerability exists in the Linux kernel's regulator subsystem where improper locking mechanisms cause a lockdep warning during error path execution in the regulator_resolve_supply() function. The issue occurs when late enabling of a supply regulator fails, triggering an inconsistent locking state that violates kernel locking protocols. The specific problem manifests when _regulator_put() is called without holding the regulator_list_mutex, which is a fundamental requirement for maintaining kernel data structure integrity. This locking violation represents a classic concurrency control failure that could potentially lead to memory corruption or system instability during regulator resource management operations.
The technical flaw stems from the improper use of kernel synchronization primitives within the error handling path of regulator resource management. When regulator_resolve_supply() encounters a failure during late enabling, it attempts to clean up regulator resources by calling _regulator_put() directly without first acquiring the necessary regulator_list_mutex lock. This violates the kernel's locking hierarchy and triggers lockdep warnings that indicate potential deadlocks or race conditions. The vulnerability directly relates to CWE-362, which describes concurrent execution issues where improper locking allows multiple threads to access shared resources simultaneously, and aligns with ATT&CK technique T1484.001 which covers privilege escalation through kernel-level resource manipulation.
The operational impact of this vulnerability extends beyond simple warning messages to potentially compromise system stability and security. While the immediate effect is a lockdep warning that may not cause immediate system failure, the underlying concurrency issue could lead to more severe problems including memory corruption, regulator resource leaks, or unpredictable system behavior during power management operations. The vulnerability affects the kernel's ability to properly manage hardware regulator resources, which are critical for power management and device operation across various hardware platforms. This issue becomes particularly concerning in embedded systems or mobile devices where precise power management is essential for both performance and battery life optimization.
The mitigation strategy involves switching from _regulator_put() to regulator_put() which properly handles the required locking mechanisms, ensuring that the regulator_list_mutex is acquired before resource cleanup operations. Additionally, the fix implements appropriate locking around the regulator device structure (rdev) during supply pointer clearing operations to prevent concurrent access issues. This approach addresses both the immediate locking violation and prevents potential race conditions that could occur during the cleanup phase of regulator resource management. The solution follows established kernel development practices for proper synchronization and resource management, ensuring that the regulator subsystem maintains data integrity throughout all operational states including error conditions. The fix also prepares the codebase for future modifications by establishing correct locking patterns that will be maintained during subsequent code removal operations.