CVE-2026-64001

What it actually does

This is a Linux kernel use-after-free in the ALSA PCM OSS compatibility layer. The vulnerable code links a newly allocated OSS PCM setup entry into a global setup list before fully initializing it. If allocation of the task-name field fails, the error path frees the entry while it remains reachable from the list. A later OSS PCM device open can traverse the stale list and dereference freed kernel memory. The most likely technical outcomes are kernel crash, denial of service, and potentially local privilege escalation if an attacker can reliably reclaim and shape the freed kernel object.

Why it matters to the business

Systems running affected Linux kernels with ALSA OSS PCM compatibility enabled may be exposed to local kernel-level instability or compromise. In practical terms, a user or process with local access could potentially crash a host or, in a more advanced exploit, gain elevated privileges. Because EPSS is currently low, there is no known CISA KEV listing, and no public exploit maturity is reported, this is not currently an internet-scale emergency; however, kernel flaws should still be prioritized on multi-user systems, shared compute platforms, developer workstations, VDI, audio-enabled desktops, and workloads where untrusted local code can run.

How an attack unfolds

An attacker first needs local code execution on a Linux system where the affected ALSA OSS PCM compatibility code is present and reachable. The attacker writes crafted input to the ALSA OSS PCM proc interface in a way that causes the task-name allocation step to fail after the setup entry has already been linked into the internal setup list. The kernel then frees the setup entry but leaves the list pointing to freed memory. The attacker subsequently opens an OSS PCM device, causing the kernel to walk the stale setup list in the OSS lookup path and dereference the freed object. A basic exploit may trigger a kernel oops or panic, causing denial of service. A more sophisticated exploit would attempt heap grooming between the free and the later dereference so the stale pointer references attacker-influenced data, which could potentially lead to privilege escalation.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream ALSA PCM OSS fix for this issue. No universal fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Where immediate patching is not possible, reduce exposure by disabling or unloading OSS PCM compatibility modules if not required, restricting access to audio device nodes and ALSA proc interfaces, preventing untrusted local code execution, and applying least-privilege controls to interactive shell, container, VDI, and shared compute environments. Reboot is typically required after a kernel update for the fix to take effect.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a build that contains the ALSA PCM OSS setup-list lifetime fix. Validate with vendor advisory metadata, changelogs, package versions, or source commits referencing the ALSA PCM OSS proc write use-after-free fix. Check whether OSS PCM compatibility is present by looking for ALSA OSS modules and interfaces such as snd_pcm_oss, /proc/asound/oss, and legacy OSS device nodes. After remediation, verify the host has rebooted into the fixed kernel with uname -a or equivalent inventory tooling. For mitigations, confirm unused OSS compatibility modules are not loaded and cannot be automatically loaded, and that access controls on audio-related proc and device interfaces are restricted as intended.

Typical attack path

1. Gain local execution on a vulnerable Linux host.
2. Confirm ALSA OSS PCM compatibility support is present and proc entries or OSS device nodes are available.
3. Write malformed or resource-exhaustion-triggering input to the ALSA OSS PCM proc configuration interface to hit the allocation-failure error path.
4. Cause the partially initialized setup entry to be freed while still linked from the OSS setup list.
5. Reclaim or influence the freed kernel memory region through heap grooming, if attempting privilege escalation rather than denial of service.
6. Open an OSS PCM device so the kernel traverses the stale setup list and dereferences freed memory.
7. Trigger a kernel crash or attempt controlled use-after-free exploitation to elevate privileges.

How to detect it

Look for evidence of local interaction with ALSA OSS PCM compatibility interfaces and subsequent kernel memory-safety faults. Useful log sources include kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, auditd logs, EDR telemetry, shell history where available, and process accounting. Search for kernel oops, panic, KASAN, slab, or general-protection-fault messages that reference snd_pcm_oss_proc_write, snd_pcm_oss_look_for_setup, snd_pcm_oss, or pcm_oss. If auditd is enabled, review writes to /proc/asound/oss/pcm or other /proc/asound/oss entries and correlate them with opens of legacy OSS devices such as /dev/dsp, /dev/audio, or /dev/mixer. Also look for suspicious local processes repeatedly writing malformed data to ALSA proc entries, intentionally exhausting memory around the write operation, or triggering repeated audio-device opens immediately before crashes. Absence of logs does not prove absence of exploitation, because a successful kernel-level exploit or panic may leave limited forensic evidence.

• /proc/asound/oss/pcm
• /proc/asound/oss
• /dev/dsp
• /dev/audio
• /dev/mixer
• snd_pcm_oss_proc_write
• snd_pcm_oss_look_for_setup
• snd_pcm_oss
• pcm_oss
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at sound/core/oss/pcm_oss.c
• Oops:
• kernel panic
• ALSA: pcm: oss

What your security team should do

• Prioritize kernel updates on systems where untrusted users or workloads can execute local code, including shared Linux servers, developer systems, desktops, VDI, CI runners, and container hosts.
• Inventory Linux assets for affected kernels and for the presence of ALSA OSS PCM compatibility components such as snd_pcm_oss and /proc/asound/oss.
• Patch through the normal distribution or vendor kernel channel and ensure systems are rebooted into the fixed kernel.
• If patching is delayed, disable or block loading of OSS PCM compatibility modules where audio OSS emulation is not required.
• Restrict local user access to audio device nodes and proc-based ALSA OSS configuration interfaces where operationally feasible.
• Monitor kernel logs for crashes or memory-safety reports involving snd_pcm_oss_proc_write, snd_pcm_oss_look_for_setup, or ALSA OSS PCM components.
• Add audit or EDR monitoring for unusual writes to ALSA OSS proc interfaces followed by OSS device opens.
• Treat confirmed kernel oops, panic, or KASAN use-after-free events in this code path as potential exploitation until disproven.