CVE-2026-64029

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 (?:?)