CVE-2026-74387

CVE CVE-2026-74387EUVD EUVD-2026-59534Published 2026-08-15T05:59:02.000ZLast changed 2026-08-17T05:46:36.000ZCVSS 7.8

What the advisory describes

In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize output teardown with event_input event_process_midi() borrows msynth->output_rfile.output and then passes the substream to dump_midi() and snd_rawmidi_kernel_write() without synchronizing with the output open/close transition. midisynth_use() also publishes output_rfile before snd_rawmidi_output_params() has finished. The last midisynth_unuse() can therefore release the same rawmidi file and free substream->runtime before snd_rawmidi_kernel_write1() takes its runtime buffer reference. That leaves the event_input path using a stale substream or runtime and can end in a NULL-deref or use-after-free. Fix this with two pieces of synchronization. Keep a short IRQ-safe spinlock only for publishing or clearing output_rfile and for pairing the output snapshot with an snd_use_lock_t reference. Once event_process_midi() has taken that in-flight reference, it drops the spinlock before calling snd_seq_dump_var_event(), dump_midi(), or snd_rawmidi_kernel_write(). midisynth_unuse() now detaches the visible rawmidi file under the same spinlock, waits for the in-flight writers to drain, and only then drains and releases the saved file. midisynth_use() likewise opens into a local snd_rawmidi_file and publishes it only after snd_rawmidi_output_params() succeeds. The buggy scenario involves two paths, with each column showing the order within that path: event_input path: last unuse path: 1. event_process_midi() snapshots 1. midisynth_unuse() starts output_rfile.output. tearing down output_rfile. 2. dump_midi() reaches 2. snd_rawmidi_kernel_release() snd_rawmidi_kernel_write() closes the output file. before runtime is pinned. 3. close_substream() frees 3. The callback keeps using substream->runtime. the borrowed substream. Validation reproduced this kernel report: KASAN null-ptr-deref in snd_rawmidi_kernel_write1+0x56/0x360 RIP: 0033:0x7fde7dd0837f RIP: 0010:snd_rawmidi_kernel_write1+0x56/0x360

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 6.18.40; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <718f6a56b40875f19e6915799044a02df9abfd52; 2.6.12; patch: 0; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <936641af564c3d92721704b781e36aaf223efdd2; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <ef7607ab1c8adc6258fb1b27d08e26aecdc18a58; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <f5d470b808bc01f70978e22e595c6f7768313406; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <11165fe2c5ea0516debe486d91df67abbe36905e; patch: 7.2; patch: 6.6.145; patch: 6.12.97; patch: 7.1.5; patch: 6.1.178; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <d6fd2afb137f52bf00c5210cc44d08ed54dcffb4

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.