From: sashiko-bot@kernel.org
To: "YuanZhe Liu" <25031212351@stu.xidian.edu.cn>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH v2] ALSA: bcd2000: Wait for open files before freeing the MIDI URBs
Date: Sat, 31 Oct 2026 18:59:41 +0000 [thread overview]
Message-ID: <sashiko-outbox-192100@kernel.org> (raw)
In-Reply-To: <20261031184405.15307-1-25031212351@stu.xidian.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ALSA: bcd2000: deadlock in bcd2000_disconnect() via snd_card_disconnect_sync()
--
commit b86f69d1ff1d65cb943f4d36efce05abcc0a498d
Author: YuanZhe Liu <25031212351@stu.xidian.edu.cn>
ALSA: bcd2000: Wait for open files before freeing the MIDI URBs
This commit replaces snd_card_disconnect() with snd_card_disconnect_sync() in
bcd2000_disconnect() so that open rawmidi files are closed before freeing the
MIDI URBs.
> diff --git a/sound/usb/bcd2000/bcd2000.c b/sound/usb/bcd2000/bcd2000.c
> index 2bd49bf827489..a5e8ea92532c5 100644
> --- a/sound/usb/bcd2000/bcd2000.c
> +++ b/sound/usb/bcd2000/bcd2000.c
> @@ -451,8 +451,13 @@ static void bcd2000_disconnect(struct usb_interface *interface)
>
> guard(mutex)(&devices_mutex);
>
> - /* make sure that userspace cannot create new requests */
> - snd_card_disconnect(bcd2k->card);
> + /*
> + * Make sure that userspace cannot create new requests, and wait
> + * until all already-open files are closed so that the rawmidi
> + * close callbacks (which may kill the out URB) run while the
> + * URBs are still valid.
> + */
> + snd_card_disconnect_sync(bcd2k->card);
[Severity: High]
Can calling snd_card_disconnect_sync() inside bcd2000_disconnect() deadlock or
stall USB disconnect processing?
In sound/core/init.c, snd_card_disconnect_sync() sleeps uninterruptibly until
all open file descriptors on the card are closed:
sound/core/init.c:snd_card_disconnect_sync() {
snd_card_disconnect(card);
guard(spinlock_irq)(&card->files_lock);
wait_event_lock_irq(card->remove_sleep,
list_empty(&card->files_list),
card->files_lock);
}
However, bcd2000_disconnect() is invoked by usb_unbind_interface() with
device_lock(&interface->dev) held, and from usb_disconnect() ->
usb_disable_device() or usbfs ioctls (usbdev_do_ioctl()) with
usb_lock_device(udev) held, and then acquires devices_mutex.
If a process holding an open ALSA fd on bcd2k->card unbinds the driver via
sysfs (/sys/bus/usb/drivers/snd-bcd2000/unbind) or issues a usbfs ioctl that
unbinds the interface (such as USBDEVFS_DISCONNECT, USBDEVFS_DISCONNECT_CLAIM,
USBDEVFS_RESET, or USBDEVFS_SETCONFIGURATION), bcd2000_disconnect() runs
synchronously in that process's syscall context and sleeps in
snd_card_disconnect_sync() waiting for that same process to close its ALSA fd.
An ABBA deadlock with usb_lock_device(udev) is also possible during
usb_disconnect(): the hub worker holds usb_lock_device(udev) while waiting in
snd_card_disconnect_sync() for open ALSA fds to close. If a process holds both
a usbfs fd (/dev/bus/usb/...) with a lower fd number and an ALSA fd on the
same device and exits (do_exit() -> close_files()) or closes the usbfs fd
first, usbdev_release() blocks on usb_lock_device(udev) before the process can
close the ALSA fd.
Even on a normal physical unplug, waiting in bcd2000_disconnect() for
userspace to close all ALSA fds blocks hub_event() on hub_wq in
TASK_UNINTERRUPTIBLE while holding devices_mutex and before device_del() emits
remove uevents, defeating the asynchronous teardown intended by
snd_card_free_when_closed(bcd2k->card) at the end of bcd2000_disconnect().
Instead of blocking in snd_card_disconnect_sync(), would it be safer to keep
snd_card_disconnect() and Either serialize midi_out_urb in
bcd2000_midi_output_close() or defer usb_free_urb() to a card->private_free
callback that runs when snd_card_free_when_closed() finishes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261031184405.15307-1-25031212351@stu.xidian.edu.cn?part=1
next prev parent reply other threads:[~2026-10-31 18:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 10:31 [PATCH 0/1] ALSA: bcd2000: fix use-after-free of MIDI URBs on disconnect Yuanzhe Liu
2026-09-23 10:31 ` [PATCH 1/1] ALSA: bcd2000: fix use-after-free of MIDI URBs on file close after disconnect Yuanzhe Liu
2026-10-30 17:37 ` [PATCH 0/1] ALSA: bcd2000: fix use-after-free of MIDI URBs on disconnect YuanZhe Liu
2026-10-31 18:06 ` Takashi Iwai
2026-10-31 18:44 ` [PATCH v2] ALSA: bcd2000: Wait for open files before freeing the MIDI URBs YuanZhe Liu
2026-10-31 18:59 ` sashiko-bot [this message]
2026-10-31 19:09 ` [PATCH v3] ALSA: bcd2000: Fix use-after-free of MIDI URBs on file close YuanZhe Liu
2026-11-01 15:32 ` Takashi Iwai
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=sashiko-outbox-192100@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=25031212351@stu.xidian.edu.cn \
--cc=linux-sound@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox