Look up another CVE · open CVE-2026-74387 in the interactive tracker

CVE-2026-74387

ALSA: seq: midi: Serialize output teardown with event_input

7.8 EPSS 0.2% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem sound/core. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-74387 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixed	6.1.180-1	Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.100-1	Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

event_process_midi() borrows msynth->output_rfile.output and then passes the substream to dump_midi() and snd_rawmidi_kernel_write() without synchronizing with the output open/close transition. midisynth_use() also publishes output_rfile before snd_rawmidi_output_params() has finished. The last midisynth_unuse() can therefore release the same rawmidi file and free substream->runtime before snd_rawmidi_kernel_write1() takes its runtime buffer reference. That leaves the event_input path using a stale substream or runtime and can end in a NULL-deref or use-after-free. Fix this with two pieces of synchronization. Keep a short IRQ-safe spinlock only for publishing or clearing output_rfile and for pairing the output snapshot with an snd_use_lock_t reference. Once event_process_midi() has taken that in-flight reference, it drops the spinlock before calling snd_seq_dump_var_event(), dump_midi(), or snd_rawmidi_kernel_write(). midisynth_unuse() now detaches the visible rawmidi file under the same spinlock, waits for the in-flight writers to drain, and only then drains and releases the saved file. midisynth_use() likewise opens into a local snd_rawmidi_file and publishes it only after snd_rawmidi_output_params() succeeds. The buggy scenario involves two paths, with each column showing the order within that path: event_input path: last unuse path: 1. event_process_midi() snapshots 1. midisynth_unuse() starts output_rfile.output. tearing down output_rfile. 2. dump_midi() reaches 2. snd_rawmidi_kernel_release() snd_rawmidi_kernel_write() closes the output file. before runtime is pinned. 3. close_substream() frees 3. The callback keeps using substream->runtime. the borrowed substream. Validation reproduced this kernel report: KASAN null-ptr-deref in snd_rawmidi_kernel_write1+0x56/0x360 RIP: 0033:0x7fde7dd0837f RIP: 0010:snd_rawmidi_kernel_write1+0x56/0x360

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

sound/core/seq/seq_midi.c

What this is: SOUNDMAINTAINERS section matched on sound/ · linux-sound@vger.kernel.org · Maintained
Kernel module: snd_seq_midi

Check it on the machine

grep -wE 'CONFIG_SND|CONFIG_SND_SEQUENCER|CONFIG_SND_SEQ_MIDI' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w snd_seq_midi

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_SND, CONFIG_SND_SEQUENCER, CONFIG_SND_SEQ_MIDI
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-15 (2 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.17%, higher than 6.0% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: sound/core

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.12	6.1.178	f5d470b808bc
2.6.12	6.6.145	936641af564c
2.6.12	6.12.97	718f6a56b408
2.6.12	6.18.40	11165fe2c5ea
2.6.12	7.1.5	d6fd2afb137f
2.6.12	7.2	ef7607ab1c8a

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The bug is reached only via local ALSA sequencer interfaces: opening /dev/snd/seq, subscribing to a MIDI synth port (SNDRV_SEQ_IOCTL_SUBSCRIBE_PORT), writing events (snd_seq_write), and unsubscribing (SNDRV_SEQ_IOCTL_UNSUBSCRIBE_PORT). There is no network, Bluetooth, or physical-device packet path to event_process_midi().
AC:LAttack complexity, low: Exploitation is a race between MIDI event delivery and the last midisynth_unuse() teardown; an attacker controls both sides by concurrently writing sequencer events and unsubscribing from the same MIDI output port. Published reproducers triggered KASAN null-deref/UAF reliably without external timing luck.
PR:LPrivileges required, low: Any unprivileged local user with standard ALSA access (typically membership in the audio group for /dev/snd/seq) can create a sequencer client, subscribe to hardware MIDI synth ports, dispatch events, and trigger teardown. No real root/CAP_SYS_ADMIN or user-namespace capability is required.
UI:NUser interaction, none: Exploitation requires no victim interaction; the attacker programmatically opens the sequencer, subscribes, floods MIDI events, and unsubscribes from their own client. No mount, file open, or other user-driven action by another party is needed.
S:UScope, unchanged: Impact is kernel memory corruption and potential local privilege escalation within the same kernel security domain. It does not cross a VM/host, IOMMU, or sandbox boundary; compromised resources remain under the same OS authority.
C:HConfidentiality impact, high: The race frees substream->runtime (kmalloc-192 snd_rawmidi_runtime) while event_process_midi() still dereferences it in dump_midi()/snd_rawmidi_kernel_write1(), producing a confirmed slab use-after-free and NULL-deref. UAF on kernel heap objects enables arbitrary memory disclosure via heap grooming.
I:HIntegrity impact, high: Use-after-free of the rawmidi runtime while the write path accesses runtime->buffer and related fields can be turned into controlled heap corruption and arbitrary kernel writes/code execution, not merely a one-shot crash. Memory corruption primitives warrant High integrity impact.
A:HAvailability impact, high: Concurrent unsubscribe frees the output runtime during an in-flight write, causing KASAN-reported null-pointer dereference and slab use-after-free in snd_rawmidi_kernel_write1(). This can oops or panic the kernel and be retriggered by repeated subscribe/write/unsubscribe cycles.