CVE-2026-53350

What it actually does

This is a Linux kernel NULL pointer dereference in the ASoC wm_adsp audio DSP control-removal path. When cs_dsp removes firmware controls, wm_adsp_control_remove() may attempt to clean up private control data even when cs_ctl->priv was never initialized. That can occur for SYSTEM controls or controls hidden by a codec driver's control_add() callback. If the vulnerable path is reached, the kernel can dereference NULL, causing an Oops, driver failure, or system crash depending on kernel configuration and recovery behavior. The impact is denial of service rather than code execution based on the available description.

Why it matters to the business

Systems using affected Linux kernels with relevant ASoC wm_adsp/cs_dsp audio codec drivers may experience unexpected crashes or service disruption when audio DSP firmware controls are removed, such as during driver unload, device removal, reboot/shutdown paths, or hardware reconfiguration. The risk is highest for embedded, appliance, mobile, industrial, or audio-focused Linux devices where sound codec drivers are enabled and stability is operationally important. EPSS is low and there is no KEV listing or known ransomware use, so broad internet-scale exploitation is unlikely, but kernel crashes can still affect availability and device reliability.

How an attack unfolds

An attacker would need a way to cause the affected kernel code path to remove cs_dsp firmware controls associated with wm_adsp. In a typical scenario, this requires local access, control over device state, permissions to unload or rebind drivers, access to relevant debug/sysfs interfaces, or the ability to trigger hardware or firmware-control teardown through a privileged management path. The attacker causes a control list teardown where at least one control has no wm_adsp private data because it is a SYSTEM control or was hidden by a codec-driver callback. The vulnerable removal function then attempts to clean up the nonexistent private data without a NULL check, leading to a kernel NULL pointer dereference and denial of service. There is currently no indication of public exploit maturity, active exploitation, or ransomware use.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix adding a NULL check in wm_adsp_control_remove() before cleaning up private control data. If using a distribution kernel, apply the vendor-provided security or stable kernel update when available. If maintaining a custom kernel, backport the upstream ASoC wm_adsp fix for the NULL dereference during firmware-control removal. Where immediate patching is not possible, reduce exposure by disabling unused wm_adsp/cs_dsp-capable audio codec drivers, preventing untrusted users from unloading/rebinding kernel drivers, restricting access to debugfs/sysfs device-management interfaces, and limiting local shell access on affected embedded or appliance devices.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the distribution advisory, kernel changelog, or source tree for the added NULL check in wm_adsp_control_remove(). Validate that affected ASoC wm_adsp/cs_dsp drivers are either patched or not built/loaded. On test systems with relevant hardware, exercise safe driver teardown paths such as controlled unbind/rebind, module unload/load if supported, shutdown/reboot, and firmware-control removal workflows, then verify no kernel Oops, panic, or NULL pointer dereference occurs. Also review kernel logs after validation for wm_adsp, cs_dsp, ASoC, Oops, BUG, or panic messages.

Typical attack path

1. Identify a Linux system running an affected kernel with ASoC wm_adsp/cs_dsp audio DSP support enabled and relevant codec hardware or drivers present.
2. Obtain local, privileged, or device-management access sufficient to trigger audio DSP firmware-control removal, driver unbind, module unload, device reset, suspend/resume edge cases, or similar teardown behavior.
3. Trigger removal of cs_dsp controls where a control lacks wm_adsp private data, such as SYSTEM controls or controls hidden by a codec driver's control_add() callback.
4. The vulnerable wm_adsp_control_remove() path dereferences a NULL private-data pointer.
5. The kernel logs an Oops or panic and the host or device experiences denial of service, reboot, driver failure, or degraded audio subsystem functionality.

How to detect it

To determine whether this issue was already triggered, review kernel logs, persistent journal data, crash dumps, and device watchdog/reboot records for evidence of a NULL pointer dereference in the ASoC wm_adsp or cs_dsp control-removal path. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel logs, pstore/ramoops records on embedded devices, kdump/vmcore artifacts, and platform management controller or watchdog reset logs. Look for crashes occurring around audio driver unload/reload, device unbind/rebind, firmware changes, suspend/resume, shutdown, reboot, or hardware reset events. There are no strong network IOCs because this is a local kernel denial-of-service condition, but repeated kernel Oops or panic messages with wm_adsp_control_remove() or cs_dsp_remove() in the stack trace are useful forensic indicators.

• wm_adsp_control_remove
• cs_dsp_remove
• wm_adsp
• cs_dsp
• ASoC: wm_adsp
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• RIP: wm_adsp_control_remove
• Call Trace: wm_adsp_control_remove
• Call Trace: cs_dsp_remove
• /sys/bus/platform/drivers
• /sys/kernel/debug
• /sys/fs/pstore
• ramoops
• vmcore

What your security team should do

• Inventory Linux systems and embedded devices that use ASoC wm_adsp/cs_dsp-capable audio codec drivers or custom kernels with these drivers enabled.
• Prioritize patching devices where audio codec drivers are active and system availability is critical, even though EPSS is low and the issue is not in CISA KEV.
• Apply vendor kernel updates or backport the upstream NULL-check fix into maintained custom kernels.
• Restrict local administrative capabilities that can unload, unbind, reset, or reconfigure kernel drivers on affected systems.
• Disable unused audio DSP codec drivers in kernel builds or module-loading policy where the hardware/functionality is not required.
• Monitor kernel logs for NULL pointer dereferences involving wm_adsp_control_remove(), cs_dsp_remove(), wm_adsp, or ASoC after driver lifecycle events.
• For appliances or embedded fleets, include this fix in the next firmware maintenance release and regression-test suspend/resume, reboot, shutdown, and audio subsystem initialization/removal paths.