In the Linux kernel, the following vulnerability has been resolved:

ALSA: seq: Serialize UMP output teardown with eventinput

sequmpprocessevent() borrows client->outrfile.output without synchronizing with the first-open and last-close transition in sequmpclientopen() and sequmpclientclose().

The last output unuse can therefore drop opened[STROUT] to zero and release the rawmidi file while an in-flight eventinput callback is still inside sndrawmidikernelwrite(). 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 eventinput-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through sndrawmidikernelwrite(). 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 eventinput 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: eventinput path path B label: last unuse path 1. sequmpprocessevent() reads 1. sequmpclientclose() client->outrfile.output. drops opened[STROUT] to zero. 2. sndrawmidikernelwrite1() 2. sndrawmidikernelrelease() has not yet pinned runtime. closes the output file. 3. The writer continues using 3. closesubstream() frees the borrowed substream. substream->runtime.

This keeps the output substream and runtime alive for the full eventinput write while keeping rawmidi release outside the rwlock.

KASAN reproduced this as a slab-use-after-free in sndrawmidikernelwrite1(), with allocation through sequmpuse()/sndseqportconnect() and free through sequmpunuse()/sndseqportdisconnect().

Validation reproduced this kernel report: KASAN slab-use-after-free in sndrawmidikernelwrite1+0x9d/0x400 RIP: 0033:0x7f5528af837f Read of size 8 Call trace: dumpstacklvl+0x73/0xb0 (?:?) printreport+0xd1/0x650 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) virtaddrvalid+0x1a7/0x340 (?:?) kasancompletemodereportinfo+0x64/0x200 (?:?) kasanreport+0xf7/0x130 (?:?) sndrawmidikernelwrite1+0x9d/0x400 (?:?) asanload8+0x82/0xb0 (?:?) updatestackstate+0x1ef/0x2d0 (?:?) sndrawmidikernelwrite+0x1a/0x20 (?:?) sequmpprocessevent+0xd4/0x120 (sound/core/seq/sequmpclient.c:82) sndseqdeliversingleevent+0x8a/0xe0 (?:?) sndseqdeliverfromump+0x2b2/0xd60 (?:?) lockacquire+0x14e/0x2e0 (?:?) findheldlock+0x31/0x90 (?:?) sndseqportuseptr+0xa6/0xe0 (?:?) kasancheckwrite+0x18/0x20 (?:?) dorawreadunlock+0x32/0xa0 (?:?) rawreadunlock+0x26/0x50 (?:?) sndseqdeliversingleevent+0x45c/0x4b0 (?:?) sndseqdeliverevent+0x10d/0x1b0 (?:?) sndseqclientenqueueevent+0x192/0x240 (?:?) sndseqwrite+0x2cd/0x450 (?:?) apparmorfilepermission+0x20/0x30 (?:?) securityfilepermission+0x51/0x60 (?:?) vfswrite+0x1ce/0x850 (?:?) fgetfiles+0x12b/0x220 (?:?) lockrelease+0xc8/0x2a0 (?:?) rcureadunlock+0x74/0x2d0 (?:?) fgetfiles+0x135/0x220 (?:?) ksyswrite+0x15a/0x180 (?:?) rcuiswatching+0x24/0x60 (?:?) x64syswrite+0x46/0x60 (?:?) x64syscall+0x7d/0x20d0 (?:?) dosyscall64+0xc1/0x360 (arch/x86/entry/syscall64.c:87) entrySYSCALL64afterhwframe+0x77/0x7f (?:?)