CVE-2026-89946: ASoC: cs35l33: drain threaded IRQ before runtime suspend
In the Linux kernel, the following vulnerability has been resolved:
ASoC: cs35l33: drain threaded IRQ before runtime suspend
cs35l33runtimesuspend() currently switches the codec into regcachecacheonly(true) and powers it down without first quiescing the threaded IRQ registered by devmrequestthreadedirq(). That leaves a window where cs35l33irqthread() can still run after suspend has closed off live register 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 INTSTATUS1/2 after cacheonly has been enabled, ignores the regmapread() failures, and can still drive the AMPSHORTRLS, CALERRRLS, OTERLS, and OTWRLS release paths.
Use disableirq() before entering cacheonly/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtimeresume() has restored live register access with regcachesync(). Since probe only warns if devmrequestthreadedirq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel cs35l33 ASoC codec driver are exposed when runtime power management suspends the codec while its fault IRQs remain unmasked and the driver's threaded IRQ was successfully installed.
What condition triggers the vulnerable race?
The race occurs when cs35l33_runtime_suspend() enables regcache cache-only mode and powers down the codec while cs35l33_irq_thread() is still running or starts running. The handler can then attempt to read volatile interrupt-status registers after live register access has been closed.
How can I determine whether a device is affected in operation?
The relevant condition is runtime suspend occurring while critical fault IRQs are unmasked. The driver may continue into AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths even when its regmap reads fail after cache-only mode is enabled.
What mitigation is described if an update cannot be applied immediately?
The described mitigation is to disable and drain the IRQ before enabling cache-only mode or powering down during runtime suspend, then re-enable it only after runtime resume restores register access and completes regcache synchronization. IRQ disable and re-enable operations must be conditional on the threaded IRQ having been installed.