CVE-2026-64029: ALSA: seq: Serialize UMP output teardown with event_input

From: Greg Kroah-Hartman <[email protected]>

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

The Linux kernel CVE team has assigned CVE-2026-64029 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.5 with commit 81fd444aa371261cd33f31d4ffd80faeeeab0cc9 and fixed in 6.6.142 with commit 8ba1c4ddbb1c67d34bb440aecb9f5690ed3f64cb
	Issue introduced in 6.5 with commit 81fd444aa371261cd33f31d4ffd80faeeeab0cc9 and fixed in 6.12.92 with commit 0cb1ad795570167558530d6194297ac2396a1991
	Issue introduced in 6.5 with commit 81fd444aa371261cd33f31d4ffd80faeeeab0cc9 and fixed in 6.18.34 with commit 3aab4a58d23fb22dac5b558bbe5df1a8dad00b4b
	Issue introduced in 6.5 with commit 81fd444aa371261cd33f31d4ffd80faeeeab0cc9 and fixed in 7.0.11 with commit ef46b616a4c219185bbf10ebcbacb571583fd0e4
	Issue introduced in 6.5 with commit 81fd444aa371261cd33f31d4ffd80faeeeab0cc9 and fixed in 7.1 with commit 60a1969fae6209644698fca91c185d153674f631

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64029
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	sound/core/seq/seq_ump_client.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/8ba1c4ddbb1c67d34bb440aecb9f5690ed3f64cb
	https://git.kernel.org/stable/c/0cb1ad795570167558530d6194297ac2396a1991
	https://git.kernel.org/stable/c/3aab4a58d23fb22dac5b558bbe5df1a8dad00b4b
	https://git.kernel.org/stable/c/ef46b616a4c219185bbf10ebcbacb571583fd0e4
	https://git.kernel.org/stable/c/60a1969fae6209644698fca91c185d153674f631