CVE-2026-64481

What it actually does

This is a local Linux kernel use-after-free flaw in the ALSA HDA Cirrus Logic CS35L41 audio amplifier driver. The driver creates ALSA controls whose private data references driver state, and a firmware-load control can queue asynchronous firmware loading work. Under specific teardown conditions, particularly when firmware autostart is disabled and firmware loading is requested before DSP initialization, component unbind or device removal can free or invalidate driver state while queued work or control callbacks can still reference it. A local attacker with sufficient privileges to interact with the relevant ALSA controls and influence device teardown can potentially trigger kernel memory corruption, leading to denial of service or, in a successful exploitation scenario, local privilege escalation with kernel-level impact to confidentiality, integrity, and availability.

Why it matters to the business

Systems using affected Linux kernels with the CS35L41 HDA audio driver may be vulnerable to local privilege escalation or crashes. The most likely operational impact is instability or kernel panic on laptops or endpoints using this audio hardware, but the CVSS impact reflects the possibility of full local compromise if the memory corruption is made exploitable. The issue is not remotely exploitable, has low EPSS, is not listed in CISA KEV, and has no known public exploit maturity in the supplied data, so remediation should be prioritized for exposed endpoint fleets and standard kernel maintenance cycles rather than emergency internet-facing response.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel and using the vulnerable ALSA HDA CS35L41 driver path. The attacker interacts with ALSA controls associated with firmware loading, queues the firmware-load work while the DSP has not been fully initialized, and then causes or races component unbind or device removal before the queued work executes. Because vulnerable versions do not reliably remove the controls on unbind and do not always cancel the queued firmware-load work during teardown, the delayed worker or a later control callback can dereference driver state that has already been torn down. This can corrupt kernel memory or crash the system; with additional exploit development, the attacker may be able to shape memory reuse and escalate privileges.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the upstream fix for the ALSA hda/cs35l41 firmware-load work teardown issue. The fix removes created ALSA controls during component unbind, cancels already queued firmware-load work, and cancels fw_load_work unconditionally during device removal before runtime power-management teardown. If fixed package versions are not yet available from the operating system vendor, apply the vendor-provided kernel security update as soon as it is released or backport the relevant upstream patch. As temporary risk reduction, restrict local shell access, limit users able to interact with audio controls or load/unload related drivers, avoid unnecessary manual driver unbind/remove operations, and consider disabling or blacklisting the affected CS35L41 HDA driver only where audio functionality is not required and operationally acceptable.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor advisory or upstream patch for the CS35L41 HDA firmware-load teardown fix. Validate that the system has rebooted into the updated kernel, not merely installed it. On representative systems, check whether the cs35l41_hda driver is present or loaded and whether ALSA controls for CS35L41 firmware loading exist. For exposure assessment, identify endpoints with Cirrus Logic CS35L41 HDA audio hardware and affected kernel builds. For fix validation, review vendor changelogs or kernel source to confirm controls are removed on component unbind and fw_load_work is cancelled unconditionally during device removal. Stability testing may include suspend/resume, driver bind/unbind, and audio firmware-load workflows on non-production test systems while monitoring kernel logs for warnings, use-after-free reports, workqueue errors, or crashes.

Typical attack path

1. Gain local authenticated access to a Linux system using the affected ALSA HDA CS35L41 driver.
2. Identify that CS35L41 ALSA controls are present and that firmware loading can be triggered through the exposed control path.
3. Request firmware loading before the DSP is fully initialized, causing fw_load_work to be queued.
4. Race the queued work against component unbind, device removal, driver reload, suspend/resume, or another teardown path.
5. Trigger execution of the stale queued worker or stale control callback after driver state has been invalidated.
6. Leverage the resulting use-after-free for kernel crash, denial of service, or potential local privilege escalation.

How to detect it

There are no supplied reports of active exploitation and no known exploit artifacts from the input. Detection should focus on endpoint and kernel telemetry. Review kernel logs, system journal, crash dumps, and EDR telemetry for CS35L41 driver activity followed by workqueue faults, use-after-free reports, general protection faults, BUG/Oops messages, or kernel panics. Prioritize systems where cs35l41_hda or related CS35L41 ALSA modules are loaded. Look for unusual sequences involving ALSA control manipulation, firmware-load requests, driver unbind/remove events, module unload/reload, suspend/resume transitions, and immediate kernel warnings or crashes. If KASAN, KFENCE, or kernel crash dumping is enabled, search reports for stale references in cs35l41_hda code paths or fw_load_work. Correlate suspicious activity with local user sessions, commands touching /sys/bus, /sys/module, ALSA mixer utilities, or module-management tools such as modprobe and rmmod.

• cs35l41_hda
• snd_hda_scodec_cs35l41
• cs35l41_remove_dsp
• fw_load_work
• ALSA: hda/cs35l41
• cs35l41
• Use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG
• Oops
• workqueue
• /sys/bus/platform/drivers/cs35l41_hda/unbind
• /sys/bus/pci/drivers/snd_hda_intel/unbind
• /sys/module/snd_hda_scodec_cs35l41
• modprobe -r snd_hda_scodec_cs35l41
• rmmod snd_hda_scodec_cs35l41
• amixer
• alsactl

What your security team should do

• Inventory Linux endpoints and laptops for loaded cs35l41_hda, snd_hda_scodec_cs35l41, or related ALSA HDA CS35L41 driver modules.
• Prioritize kernel updates for systems where untrusted or semi-trusted local users have shell access, physical access, or access to audio-control interfaces.
• Track distribution advisories and deploy the first kernel package that includes the ALSA hda/cs35l41 teardown fix; reboot systems after installation.
• If patching is delayed, reduce local attack surface by restricting interactive access and administrative ability to unbind devices or unload/reload kernel modules.
• Monitor kernel logs for CS35L41 driver errors, ALSA control activity, workqueue warnings, KASAN use-after-free reports, general protection faults, and unexpected kernel panics.
• Treat suspicious crashes involving cs35l41_hda or fw_load_work as potentially security-relevant until ruled out.
• Because this is not KEV-listed, not associated with ransomware in the supplied data, and has very low EPSS, handle as a high-impact local kernel issue rather than an active mass-exploitation emergency.