Description
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 (?:?)
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 (?:?)
Published:
2026-07-19
Score:
n/a
EPSS:
n/a
KEV:
No
Impact:
n/a
Action:
n/a
Analysis and contextual insights are available on OpenCVE Cloud.
Remediation
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
Advisories
No advisories yet.
References
History
Sun, 19 Jul 2026 15:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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 (?:?) | |
| Title | ALSA: seq: Serialize UMP output teardown with event_input | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-07-19T15:39:20.368Z
Reserved: 2026-07-19T07:54:57.028Z
Link: CVE-2026-64029
No data.
No data.
No data.
OpenCVE Enrichment
No data.
Weaknesses
No weakness.