CVE-2026-80581: ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout
ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.154 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.46 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.1.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.1.10-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 7.2.12-1Fixed in 7.2.14-1 - Configuration
Ignore IPC errors during pipeline state changes and continue setting the pipeline state when the firmware state is crashed or the IPC has timed out, allowing the kernel to reset its internal state before the DSP is booted again.
Linux kernel ASoC SOF ipc4-pcm pipeline trigger IPC error handling = continue pipeline state changes when firmware is crashed or IPC has timed out
Event History
Frequently Asked Questions
Does an IPC timeout mean the DSP firmware did not receive the pipeline state-change request?
Not necessarily. The timeout has been root-caused to system scheduling blockage outside the SOF stack; the firmware may have received and handled the message while reply handling was blocked.
Why must pipeline state changes continue after a firmware crash?
The kernel must complete its internal state transitions so it can reset its state correctly and work properly when the DSP is booted again.