PT-2026-61346 · Linux · Linux

CVE-2026-64029

·

Published

2026-07-19

·

Updated

2026-07-19

CVSS v3.1

7.8

High

VectorAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Serialize UMP output teardown with event input
seq ump process event() borrows client->out rfile.output without synchronizing with the first-open and last-close transition in seq ump client open() and seq ump client close().
The last output unuse can therefore drop opened[STR OUT] to zero and release the rawmidi file while an in-flight event input callback is still inside snd rawmidi kernel write(). That leaves the rawmidi substream runtime exposed to teardown before the write path has taken its own buffer reference.
Add a per-client rwlock for the event input-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through snd rawmidi kernel write(). The last output close copies and clears the visible output file under the write side, then drops the lock and releases the saved rawmidi file. Use IRQ-safe rwlock guards because event input can also be reached from atomic sequencer delivery.
The buggy scenario involves two paths, with each column showing the order within that path:
path A label: event input path path B label: last unuse path
  1. seq ump process event() reads 1. seq ump client close() client->out rfile.output. drops opened[STR OUT] to zero.
  2. snd rawmidi kernel write1() 2. snd rawmidi kernel release() has not yet pinned runtime. closes the output file.
  3. The writer continues using 3. close substream() frees the borrowed substream. substream->runtime.
This keeps the output substream and runtime alive for the full event input write while keeping rawmidi release outside the rwlock.
KASAN reproduced this as a slab-use-after-free in snd rawmidi kernel write1(), with allocation through seq ump use()/snd seq port connect() and free through seq ump unuse()/snd seq port disconnect().
Validation reproduced this kernel report: KASAN slab-use-after-free in snd rawmidi kernel write1+0x9d/0x400 RIP: 0033:0x7f5528af837f Read of size 8 Call trace: dump stack lvl+0x73/0xb0 (?:?) print report+0xd1/0x650 (?:?) srso alias return thunk+0x5/0xfbef5 (?:?) virt addr valid+0x1a7/0x340 (?:?) kasan complete mode report info+0x64/0x200 (?:?) kasan report+0xf7/0x130 (?:?) snd rawmidi kernel write1+0x9d/0x400 (?:?) asan load8+0x82/0xb0 (?:?) update stack state+0x1ef/0x2d0 (?:?) snd rawmidi kernel write+0x1a/0x20 (?:?) seq ump process event+0xd4/0x120 (sound/core/seq/seq ump client.c:82) snd seq deliver single event+0x8a/0xe0 (?:?) snd seq deliver from ump+0x2b2/0xd60 (?:?) lock acquire+0x14e/0x2e0 (?:?) find held lock+0x31/0x90 (?:?) snd seq port use ptr+0xa6/0xe0 (?:?) kasan check write+0x18/0x20 (?:?) do raw read unlock+0x32/0xa0 (?:?) raw read unlock+0x26/0x50 (?:?) snd seq deliver single event+0x45c/0x4b0 (?:?) snd seq deliver event+0x10d/0x1b0 (?:?) snd seq client enqueue event+0x192/0x240 (?:?) snd seq write+0x2cd/0x450 (?:?) apparmor file permission+0x20/0x30 (?:?) security file permission+0x51/0x60 (?:?) vfs write+0x1ce/0x850 (?:?) fget files+0x12b/0x220 (?:?) lock release+0xc8/0x2a0 (?:?) rcu read unlock+0x74/0x2d0 (?:?) fget files+0x135/0x220 (?:?) ksys write+0x15a/0x180 (?:?) rcu is watching+0x24/0x60 (?:?) x64 sys write+0x46/0x60 (?:?) x64 sys call+0x7d/0x20d0 (?:?) do syscall 64+0xc1/0x360 (arch/x86/entry/syscall 64.c:87) entry SYSCALL 64 after hwframe+0x77/0x7f (?:?)

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-64029

Affected Products

Linux