CVE-2024-41056

What it actually does

Use of strlen() on name fields in V1 wmfw files can read past the end of fixed-size NUL-terminated arrays when the terminator is absent, resulting in an out-of-bounds read.

Why it matters to the business

Kernel-level processing of untrusted firmware files on Linux systems using affected audio DSP drivers can lead to crashes, denial of service, or potential escalation of privileges; organizations running recent stable kernels must apply updates promptly to maintain system stability.

How an attack unfolds

An attacker supplies a crafted V1 wmfw firmware file containing algorithm or coefficient name arrays lacking a terminating NUL byte; when the cs_dsp driver parses the file it calls strlen() on the unterminated buffer, reading past the array bounds and potentially triggering memory corruption or information disclosure.

How to fix it

Upgrade the Linux kernel to a version containing commit 16d76857d6b5426f41b587d0bb925de3f25bfb21 or later; rebuild and reboot with the patched kernel; verify the cs_dsp driver no longer uses strlen() on the affected name arrays.

How to confirm the fix worked

Confirm the running kernel contains commit 16d76857d6b5426f41b587d0bb925de3f25bfb21; inspect the cs_dsp source for replacement of strlen() with strnlen() on algorithm and coefficient name arrays; attempt to load a test V1 wmfw file lacking NUL terminators and verify no out-of-bounds access occurs.

Typical attack path

1. Identify a Linux system using the cs_dsp driver with V1 wmfw firmware loading enabled
2. Craft or obtain a malicious V1 wmfw file with missing NUL terminators in name fields
3. Cause the target system to load the firmware file through normal device initialization or driver reload
4. Trigger strlen() on the malformed name arrays leading to out-of-bounds access

How to detect it

Review kernel logs for cs_dsp firmware parsing warnings or oops reports around the time of firmware load events; examine audit logs for unexpected firmware file accesses; correlate with process execution of tools that trigger driver reload.

What your security team should do

• Apply the kernel patch containing commit 16d76857d6b5426f41b587d0bb925de3f25bfb21 within the next maintenance window
• Inventory all systems that load V1 wmfw firmware via cs_dsp and prioritize patching those exposed to untrusted firmware sources
• Monitor kernel logs for firmware parsing errors after patching to confirm correct behavior