CVE-2026-43437

What it actually does

This vulnerability is a use-after-free in the Linux kernel ALSA PCM subsystem during snd_pcm_drain() handling of linked audio streams. The drain path can switch a local runtime pointer to a linked stream's runtime, release the stream lock, and then continue reading fields from that runtime after it may have been freed by a concurrent close() path. A local user with access to ALSA PCM device nodes can potentially race drain and close operations on linked streams to dereference freed kernel memory. Depending on heap state and exploitability on a given kernel build, this can cause a kernel crash or potentially enable local privilege escalation through controlled use-after-free behavior.

Why it matters to the business

Successful exploitation can disrupt Linux systems by triggering kernel crashes and may allow a local low-privileged user to gain elevated privileges. The issue is local-only and requires access to audio device interfaces, so internet-facing exposure is not the primary concern; however, multi-user workstations, developer systems, shared Linux servers with audio device access, desktop fleets, kiosk systems, and containerized workloads with passed-through sound devices may be affected. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity, but it still affects a core kernel subsystem and should be remediated through normal kernel update processes.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a vulnerable Linux system and confirms access to ALSA PCM device nodes such as /dev/snd/pcm*. The attacker opens two or more linked PCM streams and repeatedly triggers snd_pcm_drain() on one stream while concurrently closing or unlinking a linked stream from another thread or process. If the race is won, the close path frees the linked stream runtime while the drain path still references it after releasing the stream lock. The immediate result may be a kernel oops or system crash. A more advanced attacker would attempt to shape kernel heap reuse around the freed runtime object so that subsequent dereferences read attacker-influenced memory, potentially turning the bug into local kernel privilege escalation. No public exploit is currently indicated by the provided metadata, so practical exploit reliability may vary significantly by kernel version, allocator behavior, hardening settings, and device permissions.

How to fix it

Apply a Linux kernel update that includes the ALSA PCM fix for the snd_pcm_drain() linked-stream runtime use-after-free. The corrected code caches no_period_wakeup, rate, and buffer_size while holding the stream lock and uses the cached values after releasing the lock. If exact fixed package versions are not yet available from the operating system vendor, track the relevant vendor kernel advisory and update to the first kernel release that contains the ALSA pcm snd_pcm_drain() fix. As interim mitigation, restrict access to sound devices by reviewing membership in audio-related groups, removing unnecessary user access to /dev/snd/*, avoiding passthrough of sound devices into containers or sandboxes, and disabling or unloading unused ALSA sound drivers where operationally feasible. Reboot systems after kernel updates to ensure the fixed kernel is running.

How to confirm the fix worked

Confirm the system is running a kernel build that contains the ALSA PCM snd_pcm_drain() use-after-free fix, not merely that the package is installed. Validate with uname -r, the distribution package manager, and vendor advisory metadata. Where source or build provenance is available, verify that the ALSA pcm change caches runtime fields before releasing the stream lock in the snd_pcm_drain() path. Check permissions on /dev/snd/* and confirm only intended users or services have access. For container and virtualization environments, verify that sound devices are not passed through unless required. After remediation, reboot and confirm the active kernel version matches the fixed package version. If a proof-of-concept or regression test is available from a trusted vendor, run it only in a non-production environment to confirm the race no longer triggers kernel warnings, oopses, or crashes.

Typical attack path

1. Gain local shell or ability to run code as a low-privileged user on a vulnerable Linux host.
2. Verify access to ALSA sound device nodes, typically under /dev/snd/.
3. Create linked ALSA PCM streams using the ALSA API or direct device interactions.
4. Trigger snd_pcm_drain() on one stream in a tight loop while racing close(), unlink, or release operations on the linked stream from another thread or process.
5. Cause the linked stream runtime object to be freed while the drain path still uses the stale pointer.
6. Attempt to produce a kernel crash for denial of service or manipulate kernel heap reuse to pursue privilege escalation.
7. If privilege escalation succeeds, establish elevated local access or execute follow-on actions as root.

How to detect it

Review kernel logs and crash artifacts for evidence of ALSA PCM-related use-after-free, kernel oops, general protection faults, BUG reports, KASAN reports, or panics occurring in or near snd_pcm_drain() and related stream-release functions. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore analysis, audit logs for access to /dev/snd/*, and endpoint telemetry showing unusual local processes repeatedly opening PCM devices. Look for patterns where unprivileged processes rapidly open, link, drain, close, or unlink ALSA PCM streams shortly before a kernel crash. If auditd is enabled, correlate SYSCALL or PATH records referencing /dev/snd/pcm* with subsequent kernel oopses. Because this is a memory-corruption race, there may be no stable file, process, or network IOC; absence of logs does not prove absence of attempted exploitation.

• snd_pcm_drain
• snd_pcm_release_substream
• snd_pcm_drop
• pcm_release_private
• snd_pcm_unlink
• snd_pcm_detach_substream
• ALSA: pcm
• /dev/snd/pcm
• /dev/snd/
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel NULL pointer dereference
• general protection fault
• kernel BUG at sound/core/pcm_native.c
• RIP: 0010:snd_pcm_drain
• Call Trace: snd_pcm_drain
• Call Trace: snd_pcm_release_substream
• Call Trace: snd_pcm_unlink

What your security team should do

• Prioritize kernel updates for Linux desktops, shared workstations, multi-user systems, and hosts where untrusted users can access ALSA sound devices.
• Inventory systems exposing /dev/snd/* and identify users, groups, services, containers, or VMs with access to audio devices.
• Restrict audio device access to only required users and workloads while patching is in progress.
• Monitor kernel logs for ALSA PCM crashes, use-after-free reports, KASAN findings, or oops traces involving snd_pcm_drain, snd_pcm_release_substream, snd_pcm_drop, snd_pcm_unlink, or snd_pcm_detach_substream.
• Reboot after applying kernel updates and verify the fixed kernel is active across the fleet.
• Treat unexplained local kernel crashes on systems with audio device access as potential exploitation attempts until reviewed.
• Do not rely on the low EPSS or absence from KEV as a reason to defer indefinitely; kernel local privilege escalation bugs can become more valuable if exploit code later becomes public.