Answer in brief
CVE-2026-74387 records a Unknown severity vulnerability in ALSA: seq: midi: Serialize output teardown with event_input. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <f5d470b808bc01f70978e22e595c6f7768313406 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <936641af564c3d92721704b781e36aaf223efdd2 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <718f6a56b40875f19e6915799044a02df9abfd52 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <11165fe2c5ea0516debe486d91df67abbe36905e || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <d6fd2afb137f52bf00c5210cc44d08ed54dcffb4 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <ef7607ab1c8adc6258fb1b27d08e26aecdc18a58 | f5d470b808bc01f70978e22e595c6f7768313406, 936641af564c3d92721704b781e36aaf223efdd2, 718f6a56b40875f19e6915799044a02df9abfd52, 11165fe2c5ea0516debe486d91df67abbe36905e, d6fd2afb137f52bf00c5210cc44d08ed54dcffb4, ef7607ab1c8adc6258fb1b27d08e26aecdc18a58 |
| Linux/Linuxgeneric | 2.6.12 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-74387 records a Unknown severity vulnerability in ALSA: seq: midi: Serialize output teardown with event_input. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <f5d470b808bc01f70978e22e595c6f7768313406 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <936641af564c3d92721704b781e36aaf223efdd2 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <718f6a56b40875f19e6915799044a02df9abfd52 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <11165fe2c5ea0516debe486d91df67abbe36905e || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <d6fd2afb137f52bf00c5210cc44d08ed54dcffb4 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <ef7607ab1c8adc6258fb1b27d08e26aecdc18a58 | f5d470b808bc01f70978e22e595c6f7768313406, 936641af564c3d92721704b781e36aaf223efdd2, 718f6a56b40875f19e6915799044a02df9abfd52, 11165fe2c5ea0516debe486d91df67abbe36905e, d6fd2afb137f52bf00c5210cc44d08ed54dcffb4, ef7607ab1c8adc6258fb1b27d08e26aecdc18a58 |
| Linux/Linuxgeneric | 2.6.12 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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
Quoted source text, attributed separately from HOL analysis.