CVE-2025-68354 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/12/2026
The vulnerability identified as CVE-2025-68354 represents a critical concurrency issue within the Linux kernel's regulator subsystem that exposes the system to multiple forms of memory corruption and inconsistent state management. This flaw exists in the core regulator framework responsible for managing power supply regulators across various hardware platforms. The regulator subsystem plays a fundamental role in power management, particularly in mobile devices, embedded systems, and servers where precise voltage regulation is essential for system stability and performance. The vulnerability specifically affects the regulator_supply_alias_list data structure which maintains mappings between regulator aliases and their actual supply sources.
The technical implementation flaw stems from insufficient synchronization mechanisms protecting access to the regulator_supply_alias_list data structure. The affected functions regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias() operate on this shared list without proper locking mechanisms. This lack of protection creates race conditions during concurrent operations where multiple threads simultaneously access the same data structure. The regulator_list_mutex already exists within the kernel codebase for protecting regulator lists, but it was not being utilized for the alias list operations, creating an inconsistency in the locking strategy. This oversight allows for direct manipulation of the linked list structure without proper mutual exclusion, leading to unpredictable behavior patterns.
The operational impact of this vulnerability manifests through several serious consequences that can compromise system stability and security. The primary risk is use-after-free conditions occurring when an alias entry is being removed from the list while another thread attempts to read from it, potentially leading to memory corruption and system crashes. Additionally, duplicate entries can be created when multiple threads simultaneously register the same alias, resulting in inconsistent regulator mappings that may cause hardware malfunctions or incorrect power management decisions. The third risk involves consumers of the regulator subsystem observing inconsistent alias mappings, which could lead to unpredictable power delivery behavior and potential system instability. These issues are particularly concerning in embedded systems and mobile devices where regulator subsystem failures can result in complete device lockups or hardware damage.
The vulnerability aligns with CWE-362, which specifically addresses race conditions in concurrent programming scenarios, and demonstrates poor synchronization practices that violate fundamental security principles. From an attack surface perspective, this vulnerability could potentially be exploited by malicious actors to cause denial-of-service conditions or, in more sophisticated scenarios, to manipulate power delivery in ways that might facilitate further attacks. The issue also maps to ATT&CK technique T1490, as it could enable system instability and resource exhaustion through regulator subsystem manipulation. The fix implemented by protecting all operations on regulator_supply_alias_list with the existing regulator_list_mutex addresses the root cause by ensuring that all traversals, insertions, and deletions occur under proper mutual exclusion. This solution maintains consistency with existing kernel locking patterns and prevents the race conditions that were previously possible. The mitigation strategy directly addresses the concurrency issues by ensuring that operations on the shared data structure are serialized, thereby preventing the memory corruption scenarios and inconsistent state conditions that could compromise system integrity and reliability.