CVE-2026-64479

What it actually does

CVE-2026-64479 is a Linux kernel information disclosure flaw in the ALSA sequencer subsystem. In UMP-enabled builds, snd_seq_event_dup() can copy a legacy ALSA sequencer event into a larger UMP event cell without clearing the trailing 4-byte field. Because the event pool is allocated with kvmalloc() and cells are reused, that trailing word may contain stale kernel heap data or leftover event data. An unprivileged local process with access to /dev/snd/seq can receive the malformed event as a UMP client using SNDRV_SEQ_FILTER_NO_CONVERT and cause snd_seq_read() to copy the uninitialized 4-byte value back to user space.

Why it matters to the business

The direct impact is limited to local disclosure of small amounts of kernel memory, but kernel information leaks can help attackers bypass exploit mitigations such as kernel address randomization or expose sensitive state that supports a larger privilege-escalation chain. Systems that expose ALSA sequencer devices to untrusted local users, containers, desktop sessions, audio workloads, or multi-user compute environments have higher practical exposure. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so remediation should be prioritized as defense-in-depth rather than as an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs local code execution on a Linux system where the ALSA sequencer device is available and the kernel is built with the affected ALSA UMP sequencer functionality. The attacker opens /dev/snd/seq as an unprivileged client, configures a UMP-capable sequencer client with the no-conversion filter, and arranges for a legacy non-UMP sequencer event to be duplicated into a pool cell. Because the vulnerable size check compares against the legacy event size instead of the full UMP cell size, the final 4-byte field is not zeroed. When the attacker reads the event back through snd_seq_read(), the kernel copies the larger UMP event structure to user space, including the stale 4-byte heap value. The attacker may repeat this to sample small fragments of kernel heap data and use the leak to support another exploit, but this vulnerability by itself does not provide code execution or privilege escalation.

How to fix it

Apply a vendor kernel update that includes the upstream fix for the ALSA sequencer snd_seq_event_dup() uninitialized heap leak. The corrected code compares the copied size against sizeof(cell->ump) so the trailing UMP word is cleared whenever a shorter event is copied. Where immediate patching is not possible, reduce exposure by restricting access to /dev/snd/seq to trusted users only, removing unnecessary users from audio-related device groups, disabling or unloading the ALSA sequencer module if not required, or blacklisting snd_seq-related modules on systems that do not need MIDI/ALSA sequencer functionality. In containerized or multi-tenant environments, avoid passing /dev/snd/seq into untrusted containers and ensure device cgroup policies prevent access to host sound devices unless explicitly required.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for the ALSA sequencer snd_seq_event_dup() issue, then reboot into the updated kernel and verify with uname -a and the operating system package manager. If building kernels internally, confirm the patch changes the comparison from sizeof(cell->event) to sizeof(cell->ump) or otherwise guarantees the UMP trailing field is initialized before copyout. Validate exposure by checking whether /dev/snd/seq exists and whether unprivileged users can open it. On systems where ALSA sequencer functionality is not required, confirm snd_seq is not loaded with lsmod and that module blacklist or device access controls remain effective after reboot.

Typical attack path

1. Gain local ability to run code on the target Linux system as an unprivileged user or within a context that can access ALSA sequencer devices.
2. Verify that /dev/snd/seq is present and accessible and that the kernel includes the affected ALSA sequencer UMP code path.
3. Create or interact with an ALSA sequencer client configured for UMP delivery and SNDRV_SEQ_FILTER_NO_CONVERT behavior.
4. Trigger duplication of a legacy ALSA sequencer event into a reusable event pool cell.
5. Read the event as a larger UMP event so the uninitialized trailing 4-byte word is copied to user space.
6. Repeat the process to gather small kernel heap disclosures and potentially combine them with another local kernel exploit.

How to detect it

There may be no durable forensic artifact because the vulnerability only leaks 4 bytes of kernel heap memory through normal device read behavior and does not necessarily crash the system or write files. Detection should focus on signs of suspicious access to the ALSA sequencer device. Review auditd, eBPF telemetry, EDR process telemetry, shell history, and container runtime logs for processes opening or repeatedly reading /dev/snd/seq, particularly from unusual executables, temporary directories, development tooling, fuzzers, or untrusted containers. If audit logging is available, add rules to record open/openat/read/ioctl activity against /dev/snd/seq. Review kernel logs for ALSA sequencer module loading on systems where it is not normally used. Because no public exploitation is currently indicated and the EPSS score is low, absence of these events does not prove safety; it only reduces evidence of attempted local probing. If suspicious access is found, preserve the process binary, command line, parent process tree, user identity, container metadata, and nearby activity that could indicate chaining with a local privilege-escalation exploit.

• /dev/snd/seq
• snd_seq
• snd_seq_event_dup
• SNDRV_SEQ_FILTER_NO_CONVERT
• SNDRV_SEQ_IOCTL_SET_CLIENT_POOL
• SNDRV_SEQ_IOCTL_SET_CLIENT_INFO
• snd_seq_read
• struct snd_seq_ump_event
• ALSA: seq
• midi_version

What your security team should do

• Patch affected Linux kernels through the normal kernel update process, prioritizing multi-user systems, developer workstations, VDI, audio-processing hosts, and container hosts that expose sound devices.
• Inventory systems where /dev/snd/seq is present and accessible to untrusted local users or containers.
• Restrict permissions to ALSA sequencer devices and remove unnecessary users from groups that grant sound device access.
• Do not pass /dev/snd/seq or broad /dev/snd access into untrusted containers unless required for a business function.
• If ALSA sequencer/MIDI functionality is unnecessary, disable or blacklist snd_seq-related modules as a temporary mitigation.
• Monitor for unusual local access to /dev/snd/seq, especially from non-audio applications, scripting runtimes, exploit test binaries, or processes in container contexts.
• Treat evidence of exploitation as a possible precursor to local privilege escalation and investigate for follow-on kernel exploit activity.