CVE-2026-93184 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl_audmix: rework runtime PM handling in probe
After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang.
Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle.
When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel driver for the Freescale Audio Mixer (fsl_audmix) contained a critical initialization flaw related to power management handling during the device probe phase. This vulnerability stems from an incorrect sequence in enabling runtime power management, which leads to hardware access failures and potential system instability. The core issue arises because calling pm_runtime_enable() merely activates the framework's ability to manage power states but does not immediately transition the device into a powered-on state. Consequently, after this call, the AUDMIX block remains in a suspended or powered-off condition until the first explicit runtime resume operation occurs. This creates a dangerous window of time between the initial probe and that first resume where any register writes issued by subsystems such as Digital Audio Interface Management (DAPM) or ALSA control paths target hardware that is not yet active.
Accessing unpowered hardware registers typically results in undefined behavior, which in this specific implementation manifests as a system hang. This occurs because the underlying bus interface cannot communicate with the peripheral when it lacks power and clock signals. The flaw represents a classic race condition where software assumes hardware readiness before physical initialization has completed. By attempting to configure audio parameters or adjust controls while the device is suspended, the kernel triggers faults that can freeze the entire system, effectively causing a denial of service for any process relying on stable kernel operation. This type of error falls under CWE-362, which covers concurrent execution errors and race conditions involving resource initialization sequences.
The resolution involves restructuring the probe function to ensure hardware readiness before allowing further configuration attempts. The fix introduces an immediate call to pm_runtime_resume_and_get() right after pm_runtime_enable(). This sequence forces the power management framework to actually turn on the device and enable its necessary clocks, ensuring that subsequent register accesses are valid. Following this initialization step, the driver releases the reference using pm_runtime_put(), which allows the runtime PM subsystem to manage the lifecycle correctly by suspending the device when it becomes idle. Crucially, this also enables the regmap framework to switch to cache-only mode during inactivity, optimizing performance and reducing power consumption without compromising functionality once the device is resumed again.
Furthermore, the patch addresses edge cases where kernel configuration disables runtime power management via CONFIG_PM or when specific platform data prevents its activation. In these scenarios, pm_runtime_* functions act as no-op stubs that do not trigger any hardware state changes. Without explicit handling for this condition, the driver would still attempt to access unpowered registers if PM is disabled but initialization logic remains unchanged. The fix explicitly calls fsl_audmix_runtime_resume() directly in such cases to guarantee that clocks are enabled and hardware is initialized regardless of the power management configuration. This ensures robust behavior across diverse kernel configurations and prevents hangs even when standard runtime PM mechanisms are bypassed.
From a security perspective, this vulnerability highlights the importance of strict resource initialization ordering in low-level drivers. While primarily causing stability issues rather than direct data exfiltration or privilege escalation, system hangs can be leveraged for denial-of-service attacks if triggered remotely through audio subsystem interfaces. The ATT&CK framework categorizes such disruptions under T1499, Endpoint Denial of Service, as the vulnerability allows an attacker to crash the host by manipulating audio controls before proper initialization completes. Mitigation strategies involve applying this kernel patch and ensuring that all peripheral drivers follow similar patterns where hardware readiness is verified or enforced immediately after enabling power management frameworks. Regular auditing of probe functions for correct PM sequencing can prevent similar issues in other subsystems, maintaining overall system resilience against stability-based attacks.