mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	baijiaju1990@gmail.com
Subject: Re: [PATCH v2] ALSA: usb-audio: Disconnect components on probe errors
Date: Thu, 18 Jun 2026 17:44:58 +0200	[thread overview]
Message-ID: <87fr2jkg3p.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260618122209.3655881-1-zzzccc427@gmail.com>

On Thu, 18 Jun 2026 14:22:09 +0200,
Cen Zhang wrote:
> 
> MIDI 2.0 input URBs can be submitted before usb_audio_probe() has
> finished building and registering the card.  If a later setup step fails,
> cleanup can reach the card or MIDI 2.0 endpoint free path while those URBs
> are still owned by the USB core.  The normal disconnect path avoids this by
> publishing the disconnected state and killing/draining URBs before endpoint
> storage and coherent transfer buffers are released.
> 
> The buggy scenario involves two paths. Each column shows path order:
> 
> probe error path:                         USB completion path:
> 1. start_input_streams() submits          1. The HCD still owns a
>    input URBs.                               submitted input URB.
> 2. A later setup helper returns           2. input_urb_complete() runs
>    an error.                                 with urb->context in ep.
> 3. Cleanup frees endpoint storage         3. The completion reads ep
>    and URB buffers.                          state and can requeue URBs.
> 
> Factor the component release sequence out of __usb_audio_disconnect() and
> call it when usb_audio_probe() is about to free a card that never claimed
> an interface.  The helper preserves the existing disconnect release order,
> including snd_usb_midi_v2_disconnect_all().
> 
> Also make the MIDI 2.0 endpoint destructor perform the local disconnect,
> kill and drain sequence only when the endpoint has not already been
> disconnected, so the internal MIDI 2.0 create-error cleanup is synchronized
> without repeating the stop sequence after normal disconnect.
> 
> Validation reproduced this kernel report:
> BUG: KASAN: slab-use-after-free in input_urb_complete+0x37/0x1b0
> Workqueue: usb_hub_wq hub_event
> RIP: 0010:_raw_spin_unlock_irq+0x2e/0x50
> Read of size 8
> Call trace:
>   dump_stack_lvl+0x77/0xb0
>   print_report+0xce/0x5f0
>   input_urb_complete+0x37/0x1b0 (sound/usb/midi2.c:186)
>   srso_alias_return_thunk+0x5/0xfbef5
>   __virt_addr_valid+0x19f/0x330
>   kasan_report+0xe0/0x110
>   __usb_hcd_giveback_urb+0x112/0x1d0
>   dummy_timer+0xaaa/0x19a0
>   lock_is_held_type+0x9a/0x110
>   __lock_acquire+0x467/0x28b0
>   mark_held_locks+0x40/0x70
>   _raw_spin_unlock_irqrestore+0x44/0x60
>   lockdep_hardirqs_on_prepare+0xbb/0x1a0
>   __hrtimer_run_queues+0x101/0x520
>   hrtimer_run_softirq+0xd0/0x130
>   handle_softirqs+0x15b/0x670
>   __irq_exit_rcu+0xd0/0x170
>   irq_exit_rcu+0xe/0x20
>   sysvec_apic_timer_interrupt+0x6c/0x80
>   asm_sysvec_apic_timer_interrupt+0x1a/0x20
> 
> Fixes: d9c99876868c ("ALSA: usb-audio: Create UMP blocks from USB MIDI GTBs")
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
> ---
> v2:
> Factor USB-audio component disconnect into the probe error path and guard
> MIDI 2.0 endpoint kill/drain with ep->disconnected, per maintainer feedback.

Please split this to two patches.  One is a quick fix for
free_midi2_endpoint() based on your original one, and another is
usb_audio_disconnect_components() I suggested -- those are basically
two distinct fixes.  And, the latter one isn't tied with the MIDI2
issue, rather a generic hardening, and I'm going to apply the second
one after 7.2 merge window, while taking the first one for 7.2-rc1.


thanks,

Takashi

  reply	other threads:[~2026-06-18 15:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 12:22 Cen Zhang
2026-06-18 15:44 ` Takashi Iwai [this message]
2026-06-18 16:57   ` Cen Zhang

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=87fr2jkg3p.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=baijiaju1990@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=zzzccc427@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®