linux-kernel - Re: [RFC PATCH] usb: xhci: Skip configure EP for disabled slots during teardown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5f0e0401-fc0b-4ac7-ab95-7f85e6677b86@linux.intel.com>
Date: Mon, 5 Jan 2026 13:02:03 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Udipto Goswami <udipto.goswami@....qualcomm.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Mathias Nyman <mathias.nyman@...el.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] usb: xhci: Skip configure EP for disabled slots
 during teardown

Hi

On 1/5/26 10:48, Udipto Goswami wrote:
> Consider a scenario when a HS headset fails resume and the hub performs
> a logical disconnect, the USB core tears down endpoints and calls
> hcd->check_bandwidth() on the way out, which with xHCI translates to a
> drop-only Configure Endpoint command (add_flags == SLOT_FLAG, drop_flags
> != 0). If the slot is already disabled (slot_id == 0) or the virtual
> device has been freed, issuing this Configure Endpoint command is
> pointless and may appear stuck until event handling catches up,
> causing unnecessary delays during disconnect teardown.
> 
> Fix this by adding a check in xhci_check_bandwidth(), return success
> immediately if slot_id == 0 or vdev is missing, preventing the
> Configure Endpoint command from being queued at all. Additionally,
> in xhci_configure_endpoint() for drop-only Configure Endpoint operations,
> return success early if slot_id == 0 or vdev is already freed,
> avoiding spurious command waits.
> 
> Signed-off-by: Udipto Goswami <udipto.goswami@....qualcomm.com>

Makes sense to prevent unnecessary 'configure endpoint' commands

Could you share more details how we end up tearing down endpoints and
calling xhci_check_bandwidth() after vdev is freed and slot_id set to zero?

Did the whole xHC controller fail to resume and was reinitialized in
xhci_resume() power_lost path?

Or is this related to audio offload and xhci sideband usage?

If we end up in this situation in normal headset resume failure then there
might be something else wrong.

Thanks
Mathias