CVE-2025-38631 in Linux
Summary
by MITRE • 08/22/2025
In the Linux kernel, the following vulnerability has been resolved:
clk: imx95-blk-ctl: Fix synchronous abort
When enabling runtime PM for clock suppliers that also belong to a power domain, the following crash is thrown: error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_mux_get_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Call trace: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8
Enabling runtime PM without explicitly resuming the device caused the power domain cut off after clk_register() is called. As a result, a crash happens when the clock hardware provider is added and attempts to access the BLK_CTL register.
Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable() and getting rid of the pm_runtime_disable() in the cleanup path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/28/2026
The vulnerability CVE-2025-38631 represents a critical synchronization issue within the Linux kernel's clock management subsystem, specifically affecting the imx95-blk-ctl driver. This flaw manifests as a synchronous external abort during runtime power management operations, demonstrating a fundamental race condition between clock supplier initialization and power domain state management. The issue occurs when runtime power management is enabled for clock suppliers that are also part of a power domain, creating a scenario where device state transitions conflict with hardware register access operations. The vulnerability is classified under CWE-665 Improper Initialization and CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization, highlighting the improper handling of shared resources during concurrent operations.
The technical flaw stems from improper power management sequence during device initialization, where the kernel attempts to access BLK_CTL registers without ensuring proper device state. The crash trace reveals execution flow through clk_mux_get_parent, clk_core_reparent_orphans_nolock, and ultimately to imx95_bc_probe, indicating that the problem occurs during clock provider registration. When clk_register() is called followed by enabling runtime PM without explicit device resumption, the power domain gets cut off, leaving the hardware registers inaccessible. This creates a scenario where subsequent hardware access attempts result in synchronous external aborts, as the underlying hardware is no longer powered or accessible. The root cause lies in the incorrect use of pm_runtime_enable() instead of devm_pm_runtime_enable(), which fails to properly manage the device's power state lifecycle during initialization and cleanup phases.
The operational impact of this vulnerability is severe, as it can lead to system crashes and complete system instability when devices utilizing the imx95-blk-ctl driver are initialized. The crash occurs during the device probe phase, making it particularly dangerous as it can prevent proper system boot sequences or cause unexpected system reboots during normal operation. This vulnerability affects embedded systems and SoC platforms that rely on the i.MX 95 processor architecture, where runtime power management is essential for power efficiency. The issue can be exploited to cause denial of service conditions, potentially allowing malicious actors to destabilize systems running affected kernel versions. The vulnerability's impact is amplified by its location in the kernel's core clock management subsystem, which is critical for system operation and device functionality.
Mitigation strategies should focus on implementing proper device power state management through the use of devm_pm_runtime_enable() instead of the standard pm_runtime_enable() function, ensuring that device resources are properly managed throughout their lifecycle. The cleanup path should avoid explicit pm_runtime_disable() calls that can interfere with the device's power management state. System administrators should ensure kernel updates are applied to address this vulnerability, particularly in embedded systems where runtime power management is actively utilized. Additionally, implementing proper error handling and device state validation during clock provider registration can help prevent similar issues in other drivers. Organizations should also consider implementing runtime power management policies that ensure proper device resumption before hardware register access operations, aligning with ATT&CK technique T1489 System Network Configuration Modification to prevent unauthorized changes to system configuration that could lead to similar vulnerabilities.