CVE-2024-56685

What it actually does

Null pointer dereference during ASoC mediatek sound card probe when num_codecs is zero or an uninitialized dummy codec is accessed, resulting in kernel panic via strcmp on a null dai_name pointer.

Why it matters to the business

Kernel crashes on boot or audio initialization can render affected Linux devices using mediatek mt8188/mt8195 sound hardware unusable until patched, increasing downtime for embedded and consumer systems.

How an attack unfolds

An attacker with local access or control over device tree configuration omits a dai link subnode or provides a node without codec property, causing the probe path in mt8188, mt8195 or mtk-soundcard-driver.c to dereference an uninitialized dummy component and trigger a panic.

How to fix it

Update to a kernel containing commit 376f4800f34a28def026ff5c5d4fc5e54e1744ff or later; rebuild and deploy the fixed kernel image for all affected mediatek platforms.

How to confirm the fix worked

Verify the running kernel contains the fix commit, confirm num_codecs check precedes codec field access in the driver source, and test probe with both missing and empty-codec DT nodes without panic.

Typical attack path

1. Obtain ability to influence device tree or kernel boot parameters
2. Omit dai link subnode or codec property in sound card node
3. Trigger sound card driver probe before card registration
4. Access num_codecs==0 or uninitialized dai_name leading to null dereference
5. Cause kernel panic

How to detect it

Search kernel logs and crash dumps for null pointer dereferences or panics originating from mediatek sound drivers during probe; inspect for references to snd-soc-dummy-dai or mtk-soundcard-driver.c.

What your security team should do

• Apply the fixed kernel version immediately on all mediatek-based devices
• Audit device tree files for sound card nodes lacking codec properties
• Monitor boot logs for sound-related kernel panics until patched