CVE-2024-27057 Affecting kernel-zfcpdump-devel package, versions *
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL8-KERNELZFCPDUMPDEVEL-6769538
- published 2 May 2024
- disclosed 1 May 2024
Introduced: 1 May 2024
CVE-2024-27057 Open this link in a new tabHow to fix?
There is no fixed version for RHEL:8
kernel-zfcpdump-devel
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel
package and not the kernel-zfcpdump-devel
package as distributed by RHEL
.
See How to fix?
for RHEL:8
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend
When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume.
If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic.
If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case.
Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot.