CVE-2026-89945: ASoC: cs35l34: drain threaded IRQ before runtime suspend
In the Linux kernel, the following vulnerability has been resolved:
ASoC: cs35l34: drain threaded IRQ before runtime suspend
cs35l34runtimesuspend() currently switches the codec into regcachecacheonly(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devmrequestthreadedirq(). That leaves a window where cs35l34irqthread() 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 INTSTATUS1..4 after cacheonly has been enabled, ignores the regmapread() failures, and can still execute the PROTRELEASECTL release sequence or the BST fault power-down writes.
Use disableirq() before entering cacheonly/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 runtimeresume() has restored live register access with regcachesync(). Since probe only logs requestthreadedirq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.
Event History
Frequently Asked Questions
Which systems can encounter this issue?
A running Linux system using the cs35l34 codec driver can reach the vulnerable window during runtime power management when critical fault IRQs remain unmasked.
What timing condition causes the unsafe access?
The condition occurs if the threaded IRQ handler runs after runtime suspend has enabled regcache cache-only mode and removed live hardware access, but before the device is resumed and register access is restored.
What does the fix need to do?
The driver should disable and drain the IRQ before enabling cache-only mode, asserting reset, or powering off the device. It should re-enable the IRQ only after runtime resume has restored live register access and completed regcache synchronization.
Is IRQ setup failure relevant to applying the fix?
Yes. Probe can continue after request_threaded_irq() fails, so the driver must track whether the IRQ was actually installed before attempting to disable or re-enable it.