From: Takashi Iwai <tiwai@suse.de>
To: Zhang Cen <rollkingzzc@gmail.com>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
zerocling0077@gmail.com, 2045gemini@gmail.com
Subject: Re: [PATCH v2] ALSA: seq: midi: Serialize output teardown with event_input
Date: Wed, 27 May 2026 12:34:48 +0200 [thread overview]
Message-ID: <87ecixw37b.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260527062948.3614025-1-rollkingzzc@gmail.com>
On Wed, 27 May 2026 08:29:48 +0200,
Zhang Cen wrote:
>
> 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
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
Applied to for-next branch now. Thanks.
Takashi
prev parent reply other threads:[~2026-05-27 10:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 6:29 [PATCH v2] ALSA: seq: midi: Serialize output teardown with event_input Zhang Cen
2026-05-27 10:34 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ecixw37b.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=2045gemini@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=rollkingzzc@gmail.com \
--cc=zerocling0077@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.