CVE-2026-89945 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ASoC: cs35l34: drain threaded IRQ before runtime suspend
cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access.
A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes.
Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel audio subsystem contains a race condition vulnerability within the cs35l34 codec driver that occurs during runtime power management transitions. This issue stems from an improper sequencing of hardware state changes relative to interrupt handling, specifically when transitioning the device into a suspended state. The core technical flaw lies in the execution order within the cs35l34_runtime_suspend function. Currently, this routine immediately switches the codec's register cache to read-only mode by calling regcache_cache_only with true, asserts the hardware reset line low, and subsequently powers off the device. Crucially, it fails to quiesce or disable the threaded interrupt handler that was previously registered using devm_request_threaded_irq during driver initialization. This omission creates a critical timing window where the system's power management logic assumes the hardware is inaccessible, while the kernel's interrupt subsystem may still schedule and execute the associated thread function.
The operational impact of this vulnerability arises when an in-flight threaded IRQ handler executes after the device has been effectively taken offline by the suspend routine. Because the register cache has already been switched to read-only mode, any subsequent attempt by the irq_thread function to access volatile status registers such as INT_STATUS_1 through INT_STATUS_4 will fail silently or return stale data if the driver does not properly handle these errors. Despite these failures in reading hardware state, the threaded handler may proceed to execute critical control sequences intended for live hardware interaction. Specifically, it might attempt to run the PROT_RELEASE_CTL release sequence or perform BST fault power-down writes. These operations target a device that is no longer powered on and whose registers are not being updated by the actual silicon, leading to undefined behavior, potential kernel panics due to null pointer dereferences if error handling is insufficient, or corruption of internal driver state machines that expect valid hardware responses.
From a security and stability perspective, this vulnerability aligns with CWE-362, which describes concurrent execution issues resulting in race conditions. The lack of synchronization between the power management subsystem removing access to resources and the interrupt handler attempting to use those same resources constitutes a classic time-of-check-to-time-of-use scenario where the state assumption made by one part of the kernel is invalidated by another asynchronous component. In terms of MITRE ATT&CK mapping, this can be viewed as an exploitation vector for Denial of Service via resource exhaustion or system instability if triggered repeatedly under load conditions that cause frequent runtime suspend-resume cycles with pending interrupts. While not directly exploitable for privilege escalation in most standard configurations, the resulting kernel instability poses a significant risk to system reliability and availability, particularly on mobile or embedded devices where aggressive power saving is common.
To mitigate this vulnerability, the driver implementation must be modified to enforce strict ordering between interrupt management and hardware state changes. The recommended fix involves disabling the threaded IRQ using disable_irq before entering the critical section that sets regcache_cache_only true, asserts reset low, and powers off the device. This ensures that any currently executing thread is allowed to complete its current iteration but prevents new instances from being scheduled while the hardware is inaccessible. Furthermore, it is essential to track whether the interrupt was successfully installed during probe, as devm_request_threaded_irq may fail silently in some error paths where only a log message is emitted. The driver should conditionally disable and re-enable interrupts based on this status flag to avoid calling operations on uninitialized IRQ descriptors. Finally, upon runtime resume, the hardware state must be fully restored via regcache_sync before any new interrupt activity is permitted by re-enabling the IRQ line. This ensures that subsequent interrupt handlers operate against a live, correctly initialized hardware environment, thereby eliminating the race condition window entirely.