CVE-2026-46090

What it actually does

This is a local use-after-free vulnerability in the Linux kernel ALSA loopback sound driver, snd-aloop. A race condition can occur when one process changes playback stream parameters while a peer capture stream is being stopped and another thread concurrently closes that peer stream. The driver may retain a stale pointer to an ALSA PCM substream/runtime after it has been detached or freed, then use that pointer during snd_pcm_stop() handling. Because the flaw is in kernel space, successful exploitation can potentially cause kernel memory corruption, kernel crash, or local privilege escalation, depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

An attacker who already has local user-level access to an affected Linux system may be able to crash the host or potentially gain elevated privileges. The most likely operational impact is denial of service on systems where the ALSA loopback driver is available, but the CVSS impact also allows for confidentiality and integrity compromise if the memory corruption is weaponized for privilege escalation. This is not listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, Linux kernel local privilege escalation issues remain important on shared servers, developer workstations, multi-user systems, containers with exposed host devices, and systems that allow untrusted local code execution.

How an attack unfolds

An attacker first needs local code execution with ordinary user privileges on a Linux system where the ALSA loopback device is present or can be made available. The attacker opens ALSA loopback playback and capture PCM streams and manipulates stream parameters so that playback startup detects a format mismatch with an active capture stream. That path causes the driver to stop the peer capture side. By racing this operation against a concurrent close of the capture stream, the attacker attempts to make the driver drop the lock, free or detach the peer runtime, and then continue operating on the stale peer substream pointer. A simple exploitation attempt may trigger a kernel oops, panic, or KASAN use-after-free report. A more advanced exploit would attempt to shape kernel heap state around the freed ALSA runtime object to convert the use-after-free into controlled kernel memory corruption and potentially gain root privileges. No public exploit maturity is reported in the provided data.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the ALSA snd-aloop fix for the peer runtime use-after-free during format-change stop. Because no exact fixed package versions were provided, use the patched kernel versions published by the relevant Linux distribution or kernel vendor and reboot into the updated kernel. As interim mitigation, disable or prevent loading of the snd-aloop module where ALSA loopback functionality is not required, restrict local shell access to trusted users, and limit access to sound devices such as /dev/snd/* on multi-user systems. If module blacklisting is acceptable, add a modprobe blacklist for snd-aloop and rebuild initramfs where required by the distribution.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor advisory or package build containing the fix, not merely that an updated package is installed. Check loaded modules with lsmod or /proc/modules to determine whether snd_aloop is in use. Validate that the snd-aloop module cannot be loaded if it has been intentionally disabled. Review distribution changelogs or kernel commit history for the ALSA aloop fix that introduces in-flight peer stop tracking and makes free_cable() wait before detaching runtime state. After patching, reboot and confirm the active kernel with uname -a or equivalent asset inventory tooling. Where feasible in test environments, run ALSA loopback stress tests under KASAN-enabled or debug kernels and verify no use-after-free, oops, or panic is produced during concurrent stream start/stop/close operations.

Typical attack path

1. Gain local user-level execution on an affected Linux system.
2. Verify that the ALSA loopback driver is loaded or that loopback PCM devices are accessible.
3. Open coordinated playback and capture streams against the ALSA loopback device.
4. Start playback with parameters that no longer match the running capture stream, causing the driver to stop the peer capture side.
5. Race the playback trigger path against a concurrent close of the capture stream.
6. Trigger use of a stale ALSA peer substream/runtime pointer after the capture runtime has been detached or freed.
7. Cause a kernel crash or attempt to convert the kernel use-after-free into privilege escalation.

How to detect it

Look for evidence of local exploitation attempts in kernel, system, audit, and endpoint telemetry. Primary log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs, EDR process telemetry, and crash dump infrastructure such as kdump or apport. Search for kernel oops, panic, general protection fault, slab corruption, or KASAN use-after-free messages that mention ALSA, snd_aloop, loopback_check_format, snd_pcm_stop, free_cable, or PCM trigger/close paths. Correlate these events with local processes opening /dev/snd devices, repeated creation or use of ALSA loopback streams, or unusual local binaries stress-testing audio devices. If crash dumps are available, inspect stack traces for snd-aloop and ALSA PCM functions and preserve the vmcore before patching. There are no network indicators because exploitation is local and does not require network traffic. Absence of these artifacts does not prove non-exploitation, because a successful privilege escalation may not leave a distinctive log entry unless it crashes or triggers kernel diagnostics.

• snd_aloop
• snd-aloop
• loopback_check_format
• snd_pcm_stop
• free_cable
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• kernel BUG at sound/drivers/aloop.c
• Oops:
• general protection fault
• slab-use-after-free
• ALSA: aloop
• /dev/snd/
• /proc/modules
• snd_aloop

What your security team should do

• Prioritize patching shared Linux systems, build hosts, developer workstations, VDI hosts, bastion systems, and any environment where untrusted users or workloads can execute local code.
• Inventory Linux systems for loaded or available snd_aloop support and exposed /dev/snd devices, especially in multi-user and containerized environments.
• Apply vendor kernel updates that include the fix and reboot systems to ensure the patched kernel is active.
• Where ALSA loopback is not business-critical, disable the snd-aloop module as a temporary hardening measure.
• Restrict local access to audio devices and avoid passing host /dev/snd devices into containers unless required.
• Monitor kernel logs for crashes, KASAN reports, or oops traces involving snd_aloop, loopback_check_format, snd_pcm_stop, or ALSA PCM close/trigger paths.
• Treat unexplained kernel crashes on systems with local untrusted users as potentially security-relevant and preserve logs, vmcores, and audit data before rebooting or rebuilding.
• Because this issue is not KEV-listed and has low EPSS, schedule broadly according to normal kernel local-privilege-escalation patch timelines, but accelerate remediation for high-density or high-trust-boundary systems.