CVE-2026-43459

What it actually does

This is a Linux kernel use-after-free in the ALSA System-on-Chip (ASoC) sound subsystem. When a sound card is unbound while a PCM audio stream is still open, the PCM close path can schedule delayed DAPM power-management work after an earlier workqueue flush has already completed. The driver teardown then frees DAI/component/DAPM widget structures before the delayed work executes, allowing snd_soc_dapm_stream_event() to dereference freed kernel memory. Successful exploitation can cause kernel memory corruption, kernel crash, or potentially local privilege escalation, depending on kernel configuration, allocator behavior, and available exploitation primitives.

Why it matters to the business

Affected Linux systems with ASoC audio support may be exposed to local denial of service or privilege escalation if an attacker can access audio devices and trigger, or induce, sound-card unbind/removal while audio streams are open. This is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, kernel-level flaws still carry high operational risk on multi-user workstations, embedded Linux devices, kiosks, appliances, and systems where untrusted users or applications can access audio interfaces.

How an attack unfolds

An attacker first needs local access to an affected Linux system and access to an ALSA PCM device. They open or maintain a PCM audio stream so that a file descriptor remains active. The vulnerable race occurs when the associated sound card is unbound or removed while that stream is still open. During teardown, snd_card_disconnect_sync() forces PCM descriptors to close, and that close path can schedule delayed DAPM stream-stop work. Because the original delayed-work flush already happened before this point, the newly scheduled work remains pending. The cleanup path then removes DAIs and components and frees the DAPM widgets referenced by the delayed work. When the delayed workqueue handler later runs, snd_soc_dapm_stream_event() accesses freed objects, causing a use-after-free. In practical attacks, exploitation is constrained by the need to line up local audio activity with device unbind/removal, but the resulting memory corruption occurs in kernel context and may be usable for a kernel crash or privilege escalation.

How to fix it

Apply the kernel update from the relevant Linux distribution or device vendor that includes the ASoC fix to flush delayed work in soc_cleanup_card_resources() after snd_card_disconnect_sync() and before removing DAIs/components/widgets. No exact fixed package versions were provided, so validate against vendor advisories and kernel changelogs for the CVE or for the upstream ASoC soc-core delayed-work flush patch. Where immediate patching is not possible, reduce exposure by limiting local access to audio devices, tightening permissions on /dev/snd/* through group membership or device policy, disabling unused audio hardware or ASoC drivers, preventing untrusted users from triggering driver unbind through sysfs, and avoiding dynamic unbind/removal of audio devices while PCM streams are active. Mitigations reduce exploitability but do not correct the kernel memory-safety flaw.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the ASoC delayed-work flush fix. Check package-manager advisory metadata, kernel changelogs, or source-level patches for changes in sound/soc/soc-core.c that flush pending delayed work after snd_card_disconnect_sync() and before soc_remove_link_dais() or soc_remove_link_components(). Verify that systems have rebooted into the fixed kernel, not merely installed it. For exposure validation, identify systems with ASoC support and loaded snd_soc* modules, accessible /dev/snd/ devices, and workflows that dynamically unbind or hot-remove audio devices. In staging only, regression-test sound-card unbind/removal while PCM streams are open and confirm no kernel oops, KASAN report, workqueue crash, or snd_soc_dapm_stream_event fault occurs.

Typical attack path

1. Gain local user-level access to a Linux system using an affected kernel with ASoC audio support.
2. Identify accessible ALSA PCM devices, commonly exposed under /dev/snd/.
3. Open and keep a PCM audio stream active through an application or direct ALSA interaction.
4. Cause or wait for the relevant sound card, platform device, or driver to be unbound or removed while the stream is open.
5. Trigger the PCM close path during card disconnect, causing delayed DAPM work to be scheduled after the earlier flush.
6. Allow teardown to free DAI/component/DAPM widget structures before the delayed work executes.
7. Leverage the resulting kernel use-after-free to crash the system or attempt local privilege escalation.

How to detect it

Look for evidence of kernel memory corruption or crashes around ALSA/ASoC device teardown rather than relying on network indicators, because this is a local kernel flaw. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops records, kdump/vmcore analysis, audit logs for writes to sysfs unbind files, and endpoint telemetry showing local processes opening /dev/snd/* shortly before audio driver unbind/removal. Search for kernel oops, panic, KASAN, KFENCE, slab-use-after-free, or workqueue faults referencing snd_soc_dapm_stream_event(), close_delayed_work, snd_soc_dapm_stream_stop(), snd_card_disconnect_sync(), soc_cleanup_card_resources(), soc_remove_link_dais(), or soc_remove_link_components(). Also correlate suspicious audio-device access by untrusted processes with subsequent writes to /sys/bus/*/drivers/*/unbind, driver unload/reload activity, or unexpected kernel crashes. Absence of these artifacts does not prove non-exploitation, because a successful privilege-escalation attempt may leave little evidence beyond transient kernel instability.

• snd_soc_dapm_stream_event
• close_delayed_work
• snd_soc_dapm_stream_stop
• snd_card_disconnect_sync
• soc_cleanup_card_resources
• soc_remove_link_dais
• soc_remove_link_components
• sound/soc/soc-core.c
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• slab-use-after-free
• general protection fault
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• kernel BUG at sound/soc/
• Workqueue: events_power_efficient
• /dev/snd/
• /sys/bus/platform/drivers/
• /unbind

What your security team should do

• Prioritize patching Linux endpoints, embedded devices, appliances, and multi-user systems that expose ASoC audio devices to untrusted users or applications.
• Inventory affected kernels and loaded ASoC-related modules, including snd_soc_core and platform-specific snd_soc_* drivers.
• Restrict membership in groups that grant access to /dev/snd/*, such as audio, to trusted users and services only.
• Audit whether unprivileged or semi-privileged users can trigger driver unbind, hotplug simulation, or device-management actions for audio hardware.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or workqueue crashes involving snd_soc_dapm_stream_event, close_delayed_work, or sound/soc/soc-core.c.
• Treat unexplained kernel crashes on systems with recent audio-device removal, driver reload, suspend/resume, or hotplug activity as potentially relevant until ruled out.
• Because this is not KEV-listed and has low EPSS, schedule according to local exposure, but do not defer indefinitely on shared-user systems because successful exploitation runs in kernel context.