CVE-2024-41039

What it actually does

Insufficient length validation when parsing wmfw firmware headers allows a buffer overrun for ADSP2 and Halo Core firmware because the check only accounted for the shorter wmfw_adsp1_sizes struct instead of the 4-byte longer wmfw_adsp2_sizes struct, enabling out-of-bounds memory access during header processing.

Why it matters to the business

Kernel-level crashes, denial of service, or potential privilege escalation on systems that load Cirrus Logic DSP firmware, increasing operational risk for embedded audio, telephony, and industrial devices that depend on the Linux kernel.

How an attack unfolds

An attacker with the ability to supply or influence firmware loading supplies a crafted wmfw file whose header size passes the flawed check yet exceeds the actual buffer allocation for ADSP2/Halo structs; when the kernel parses the longer wmfw_adsp2_sizes fields, memory beyond the buffer is accessed, which can be leveraged for code execution or crash depending on memory layout.

How to fix it

Apply the upstream fix by updating the Linux kernel to commit fd035f0810b33c2a8792effdb82bf35920221565 or later stable releases that contain the corrected three-part length validation for wmfw_header, wmfw_adsp?_sizes, and wmfw_footer.

How to confirm the fix worked

Verify the running kernel contains commit fd035f0810b33c2a8792effdb82bf35920221565 or a backported equivalent; inspect cs_dsp source for separate length checks on each header component before use; attempt to load both ADSP1 and ADSP2 test firmware to confirm no overrun occurs.

Typical attack path

1. Gain local access or the ability to trigger firmware reload on a target Linux system
2. Craft or obtain a malicious wmfw firmware file sized to exploit the header length miscalculation
3. Cause the cs_dsp driver to parse the firmware (via device probe, sysfs, or driver reload)
4. Trigger the insufficient bounds check and subsequent out-of-bounds access during header parsing

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for cs_dsp firmware header parsing warnings or oops messages around firmware load events; correlate with process activity that invokes request_firmware or sysfs firmware triggers; examine any core dumps or crash reports referencing wmfw structs.

What your security team should do

• Patch affected kernels to the fixed commit immediately, prioritizing systems that load Cirrus Logic DSP firmware
• Restrict untrusted firmware loading via module parameters or SELinux policies until patched
• Monitor kernel logs for cs_dsp or firmware parsing errors that may indicate attempted exploitation