CVE-2024-27057

What it actually does

Improper error handling in sof_ipc4_trigger_pipelines during forced pipeline reset on firmware crash causes kernel and DSP state misalignment after reboot, leading to repeated IPC failures on audio resume.

Why it matters to the business

Audio playback and capture may fail to recover after system suspend on Linux systems when DSP firmware crashes, disrupting multimedia workloads and requiring reboots or restarts.

How an attack unfolds

An attacker induces a DSP firmware panic during active audio streams followed by system suspend; the missing error suppression in the reset path leaves the kernel state inconsistent with the next firmware boot, causing audio to remain broken until the second DSP boot.

How to fix it

Update the Linux kernel to a version containing commit 3cac6eebea9b4bc5f041e157e45c76e212ad6759 in the stable tree.

How to confirm the fix worked

Verify the presence of commit 3cac6eebea9b4bc5f041e157e45c76e212ad6759 in the kernel source or confirm the fixed behavior by checking that sof_ipc4_pcm_hw_free ignores errors only for SOF_IPC4_PIPE_RESET during suspend paths.

Typical attack path

1. Start audio playback or capture on a SOF-enabled system
2. Trigger a firmware crash while audio is active
3. Initiate system suspend
4. Resume the system and observe persistent IPC errors on audio restart

How to detect it

Search kernel logs for repeated IPC errors from sof_ipc4_set_multi_pipeline_state or sof_ipc4_trigger_pipelines around suspend and resume events; correlate with firmware crash indicators in dmesg.

What your security team should do

• Prioritize kernel updates containing the referenced commit for all affected distributions
• Monitor system logs for SOF IPC errors around suspend/resume cycles
• Test audio resume behavior after applying the fix in staging environments