--- /dev/null
+From baadf2a5c26e802a46573eaad331b427b49aaa36 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 29 Oct 2025 10:30:29 +0100
+Subject: most: usb: fix double free on late probe failure
+
+From: Johan Hovold <johan@kernel.org>
+
+commit baadf2a5c26e802a46573eaad331b427b49aaa36 upstream.
+
+The MOST subsystem has a non-standard registration function which frees
+the interface on registration failures and on deregistration.
+
+This unsurprisingly leads to bugs in the MOST drivers, and a couple of
+recent changes turned a reference underflow and use-after-free in the
+USB driver into several double free and a use-after-free on late probe
+failures.
+
+Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
+Fixes: 4b1270902609 ("most: usb: Fix use-after-free in hdm_disconnect")
+Fixes: a8cc9e5fcb0e ("most: usb: hdm_probe: Fix calling put_device() before device initialization")
+Cc: stable@vger.kernel.org
+Cc: Christian Gromm <christian.gromm@microchip.com>
+Cc: Victoria Votokina <Victoria.Votokina@kaspersky.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://patch.msgid.link/20251029093029.28922-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/most/most_usb.c | 14 +++++---------
+ 1 file changed, 5 insertions(+), 9 deletions(-)
+
+--- a/drivers/most/most_usb.c
++++ b/drivers/most/most_usb.c
+@@ -1058,7 +1058,7 @@ hdm_probe(struct usb_interface *interfac
+
+ ret = most_register_interface(&mdev->iface);
+ if (ret)
+- goto err_free_busy_urbs;
++ return ret;
+
+ mutex_lock(&mdev->io_mutex);
+ if (le16_to_cpu(usb_dev->descriptor.idProduct) == USB_DEV_ID_OS81118 ||
+@@ -1068,8 +1068,7 @@ hdm_probe(struct usb_interface *interfac
+ if (!mdev->dci) {
+ mutex_unlock(&mdev->io_mutex);
+ most_deregister_interface(&mdev->iface);
+- ret = -ENOMEM;
+- goto err_free_busy_urbs;
++ return -ENOMEM;
+ }
+
+ mdev->dci->dev.init_name = "dci";
+@@ -1078,18 +1077,15 @@ hdm_probe(struct usb_interface *interfac
+ mdev->dci->dev.release = release_dci;
+ if (device_register(&mdev->dci->dev)) {
+ mutex_unlock(&mdev->io_mutex);
++ put_device(&mdev->dci->dev);
+ most_deregister_interface(&mdev->iface);
+- ret = -ENOMEM;
+- goto err_free_dci;
++ return -ENOMEM;
+ }
+ mdev->dci->usb_device = mdev->usb_device;
+ }
+ mutex_unlock(&mdev->io_mutex);
+ return 0;
+-err_free_dci:
+- put_device(&mdev->dci->dev);
+-err_free_busy_urbs:
+- kfree(mdev->busy_urbs);
++
+ err_free_ep_address:
+ kfree(mdev->ep_address);
+ err_free_cap:
slimbus-ngd-fix-reference-count-leak-in-qcom_slim_ngd_notify_slaves.patch
firmware-stratix10-svc-fix-bug-in-saving-controller-data.patch
serial-amba-pl011-prefer-dma_mapping_error-over-explicit-address-checking.patch
+most-usb-fix-double-free-on-late-probe-failure.patch
+usb-cdns3-fix-double-resource-release-in-cdns3_pci_probe.patch
+usb-gadget-f_eem-fix-memory-leak-in-eem_unwrap.patch
+usb-storage-fix-memory-leak-in-usb-bulk-transport.patch
+usb-storage-remove-subclass-and-protocol-overrides-from-novatek-quirk.patch
+usb-storage-sddr55-reject-out-of-bound-new_pba.patch
+usb-uas-fix-urb-unmapping-issue-when-the-uas-device-is-remove-during-ongoing-data-transfer.patch
+usb-dwc3-fix-race-condition-between-concurrent-dwc3_remove_requests-call-paths.patch
+xhci-dbgtty-fix-data-corruption-when-transmitting-data-form-dbc-to-host.patch
+xhci-dbgtty-fix-device-unregister.patch
--- /dev/null
+From 1ec39d2cd88dac2e7cdbac248762f1f057971c5d Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Sun, 26 Oct 2025 17:08:59 +0800
+Subject: usb: cdns3: Fix double resource release in cdns3_pci_probe
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit 1ec39d2cd88dac2e7cdbac248762f1f057971c5d upstream.
+
+The driver uses pcim_enable_device() to enable the PCI device,
+the device will be automatically disabled on driver detach through
+the managed device framework. The manual pci_disable_device() calls
+in the error paths are therefore redundant and should be removed.
+
+Found via static anlaysis and this is similar to commit 99ca0b57e49f
+("thermal: intel: int340x: processor: Fix warning during module unload").
+
+Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Acked-by: Peter Chen <peter.chen@kernel.org>
+Link: https://patch.msgid.link/20251026090859.33107-1-linmq006@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/cdns3/cdns3-pci-wrap.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/drivers/usb/cdns3/cdns3-pci-wrap.c
++++ b/drivers/usb/cdns3/cdns3-pci-wrap.c
+@@ -101,10 +101,8 @@ static int cdns3_pci_probe(struct pci_de
+ wrap = pci_get_drvdata(func);
+ } else {
+ wrap = kzalloc(sizeof(*wrap), GFP_KERNEL);
+- if (!wrap) {
+- pci_disable_device(pdev);
++ if (!wrap)
+ return -ENOMEM;
+- }
+ }
+
+ res = wrap->dev_res;
+@@ -163,7 +161,6 @@ static int cdns3_pci_probe(struct pci_de
+ /* register platform device */
+ wrap->plat_dev = platform_device_register_full(&plat_info);
+ if (IS_ERR(wrap->plat_dev)) {
+- pci_disable_device(pdev);
+ err = PTR_ERR(wrap->plat_dev);
+ kfree(wrap);
+ return err;
--- /dev/null
+From e4037689a366743c4233966f0e74bc455820d316 Mon Sep 17 00:00:00 2001
+From: Manish Nagar <manish.nagar@oss.qualcomm.com>
+Date: Thu, 20 Nov 2025 13:14:35 +0530
+Subject: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths
+
+From: Manish Nagar <manish.nagar@oss.qualcomm.com>
+
+commit e4037689a366743c4233966f0e74bc455820d316 upstream.
+
+This patch addresses a race condition caused by unsynchronized
+execution of multiple call paths invoking `dwc3_remove_requests()`,
+leading to premature freeing of USB requests and subsequent crashes.
+
+Three distinct execution paths interact with `dwc3_remove_requests()`:
+Path 1:
+Triggered via `dwc3_gadget_reset_interrupt()` during USB reset
+handling. The call stack includes:
+- `dwc3_ep0_reset_state()`
+- `dwc3_ep0_stall_and_restart()`
+- `dwc3_ep0_out_start()`
+- `dwc3_remove_requests()`
+- `dwc3_gadget_del_and_unmap_request()`
+
+Path 2:
+Also initiated from `dwc3_gadget_reset_interrupt()`, but through
+`dwc3_stop_active_transfers()`. The call stack includes:
+- `dwc3_stop_active_transfers()`
+- `dwc3_remove_requests()`
+- `dwc3_gadget_del_and_unmap_request()`
+
+Path 3:
+Occurs independently during `adb root` execution, which triggers
+USB function unbind and bind operations. The sequence includes:
+- `gserial_disconnect()`
+- `usb_ep_disable()`
+- `dwc3_gadget_ep_disable()`
+- `dwc3_remove_requests()` with `-ESHUTDOWN` status
+
+Path 3 operates asynchronously and lacks synchronization with Paths
+1 and 2. When Path 3 completes, it disables endpoints and frees 'out'
+requests. If Paths 1 or 2 are still processing these requests,
+accessing freed memory leads to a crash due to use-after-free conditions.
+
+To fix this added check for request completion and skip processing
+if already completed and added the request status for ep0 while queue.
+
+Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
+Cc: stable <stable@kernel.org>
+Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Signed-off-by: Manish Nagar <manish.nagar@oss.qualcomm.com>
+Link: https://patch.msgid.link/20251120074435.1983091-1-manish.nagar@oss.qualcomm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc3/ep0.c | 1 +
+ drivers/usb/dwc3/gadget.c | 7 +++++++
+ 2 files changed, 8 insertions(+)
+
+--- a/drivers/usb/dwc3/ep0.c
++++ b/drivers/usb/dwc3/ep0.c
+@@ -92,6 +92,7 @@ static int __dwc3_gadget_ep0_queue(struc
+ req->request.actual = 0;
+ req->request.status = -EINPROGRESS;
+ req->epnum = dep->number;
++ req->status = DWC3_REQUEST_STATUS_QUEUED;
+
+ list_add_tail(&req->list, &dep->pending_list);
+
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -229,6 +229,13 @@ void dwc3_gadget_giveback(struct dwc3_ep
+ {
+ struct dwc3 *dwc = dep->dwc;
+
++ /*
++ * The request might have been processed and completed while the
++ * spinlock was released. Skip processing if already completed.
++ */
++ if (req->status == DWC3_REQUEST_STATUS_COMPLETED)
++ return;
++
+ dwc3_gadget_del_and_unmap_request(dep, req, status);
+ req->status = DWC3_REQUEST_STATUS_COMPLETED;
+
--- /dev/null
+From e4f5ce990818d37930cd9fb0be29eee0553c59d9 Mon Sep 17 00:00:00 2001
+From: Kuen-Han Tsai <khtsai@google.com>
+Date: Mon, 3 Nov 2025 20:17:59 +0800
+Subject: usb: gadget: f_eem: Fix memory leak in eem_unwrap
+
+From: Kuen-Han Tsai <khtsai@google.com>
+
+commit e4f5ce990818d37930cd9fb0be29eee0553c59d9 upstream.
+
+The existing code did not handle the failure case of usb_ep_queue in the
+command path, potentially leading to memory leaks.
+
+Improve error handling to free all allocated resources on usb_ep_queue
+failure. This patch continues to use goto logic for error handling, as the
+existing error handling is complex and not easily adaptable to auto-cleanup
+helpers.
+
+kmemleak results:
+ unreferenced object 0xffffff895a512300 (size 240):
+ backtrace:
+ slab_post_alloc_hook+0xbc/0x3a4
+ kmem_cache_alloc+0x1b4/0x358
+ skb_clone+0x90/0xd8
+ eem_unwrap+0x1cc/0x36c
+ unreferenced object 0xffffff8a157f4000 (size 256):
+ backtrace:
+ slab_post_alloc_hook+0xbc/0x3a4
+ __kmem_cache_alloc_node+0x1b4/0x2dc
+ kmalloc_trace+0x48/0x140
+ dwc3_gadget_ep_alloc_request+0x58/0x11c
+ usb_ep_alloc_request+0x40/0xe4
+ eem_unwrap+0x204/0x36c
+ unreferenced object 0xffffff8aadbaac00 (size 128):
+ backtrace:
+ slab_post_alloc_hook+0xbc/0x3a4
+ __kmem_cache_alloc_node+0x1b4/0x2dc
+ __kmalloc+0x64/0x1a8
+ eem_unwrap+0x218/0x36c
+ unreferenced object 0xffffff89ccef3500 (size 64):
+ backtrace:
+ slab_post_alloc_hook+0xbc/0x3a4
+ __kmem_cache_alloc_node+0x1b4/0x2dc
+ kmalloc_trace+0x48/0x140
+ eem_unwrap+0x238/0x36c
+
+Fixes: 4249d6fbc10f ("usb: gadget: eem: fix echo command packet response issue")
+Cc: stable@kernel.org
+Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
+Link: https://patch.msgid.link/20251103121814.1559719-1-khtsai@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_eem.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/function/f_eem.c
++++ b/drivers/usb/gadget/function/f_eem.c
+@@ -479,8 +479,13 @@ static int eem_unwrap(struct gether *por
+ req->complete = eem_cmd_complete;
+ req->zero = 1;
+ req->context = ctx;
+- if (usb_ep_queue(port->in_ep, req, GFP_ATOMIC))
++ if (usb_ep_queue(port->in_ep, req, GFP_ATOMIC)) {
+ DBG(cdev, "echo response queue fail\n");
++ kfree(ctx);
++ kfree(req->buf);
++ usb_ep_free_request(ep, req);
++ dev_kfree_skb_any(skb2);
++ }
+ break;
+
+ case 1: /* echo response */
--- /dev/null
+From 41e99fe2005182139b1058db71f0d241f8f0078c Mon Sep 17 00:00:00 2001
+From: Desnes Nunes <desnesn@redhat.com>
+Date: Fri, 31 Oct 2025 01:34:36 -0300
+Subject: usb: storage: Fix memory leak in USB bulk transport
+
+From: Desnes Nunes <desnesn@redhat.com>
+
+commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream.
+
+A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
+Test Project (LTP). The following bytes were mainly observed: 0x53425355.
+
+When USB storage devices incorrectly skip the data phase with status data,
+the code extracts/validates the CSW from the sg buffer, but fails to clear
+it afterwards. This leaves status protocol data in srb's transfer buffer,
+such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
+lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
+interfaces, such as the one seen here when the LTP test requested 512 KiB.
+
+Fix the leak by zeroing the CSW data in srb's transfer buffer immediately
+after the validation of devices that skip data phase.
+
+Note: Differently from CVE-2018-1000204, which fixed a big leak by zero-
+ing pages at allocation time, this leak occurs after allocation, when USB
+protocol data is written to already-allocated sg pages.
+
+Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Desnes Nunes <desnesn@redhat.com>
+Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/transport.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/drivers/usb/storage/transport.c
++++ b/drivers/usb/storage/transport.c
+@@ -1204,7 +1204,23 @@ int usb_stor_Bulk_transport(struct scsi_
+ US_BULK_CS_WRAP_LEN &&
+ bcs->Signature ==
+ cpu_to_le32(US_BULK_CS_SIGN)) {
++ unsigned char buf[US_BULK_CS_WRAP_LEN];
++
+ usb_stor_dbg(us, "Device skipped data phase\n");
++
++ /*
++ * Devices skipping data phase might leave CSW data in srb's
++ * transfer buffer. Zero it to prevent USB protocol leakage.
++ */
++ sg = NULL;
++ offset = 0;
++ memset(buf, 0, sizeof(buf));
++ if (usb_stor_access_xfer_buf(buf,
++ US_BULK_CS_WRAP_LEN, srb, &sg,
++ &offset, TO_XFER_BUF) !=
++ US_BULK_CS_WRAP_LEN)
++ usb_stor_dbg(us, "Failed to clear CSW data\n");
++
+ scsi_set_resid(srb, transfer_length);
+ goto skipped_data_phase;
+ }
--- /dev/null
+From df5fde297e617041449f603ed5f646861c80000b Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 21 Nov 2025 16:29:34 -0500
+Subject: USB: storage: Remove subclass and protocol overrides from Novatek quirk
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit df5fde297e617041449f603ed5f646861c80000b upstream.
+
+A report from Oleg Smirnov indicates that the unusual_devs quirks
+entry for the Novatek camera does not need to override the subclass
+and protocol parameters:
+
+[3266355.209532] usb 1-3: new high-speed USB device number 10 using xhci_hcd
+[3266355.333031] usb 1-3: New USB device found, idVendor=0603, idProduct=8611, bcdDevice= 1.00
+[3266355.333040] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
+[3266355.333043] usb 1-3: Product: YICARCAM
+[3266355.333045] usb 1-3: Manufacturer: XIAO-YI
+[3266355.333047] usb 1-3: SerialNumber: 966110000000100
+[3266355.338621] usb-storage 1-3:1.0: USB Mass Storage device detected
+[3266355.338817] usb-storage 1-3:1.0: Quirks match for vid 0603 pid 8611: 4000
+[3266355.338821] usb-storage 1-3:1.0: This device (0603,8611,0100 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h (kernel 6.16.10-arch1-1)
+ Please send a copy of this message to
+<linux-usb@vger.kernel.org> and <usb-storage@lists.one-eyed-alien.net>
+
+The overrides are harmless but they do provoke the driver into logging
+this annoying message. Update the entry to remove the unneeded entries.
+
+Reported-by: stealth <oleg.smirnov.1988@gmail.com>
+Closes: https://lore.kernel.org/CAKxjRRxhC0s19iEWoN=pEMqXJ_z8w_moC0GCXSqSKCcOddnWjQ@mail.gmail.com/
+Fixes: 6ca8af3c8fb5 ("USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera")
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: stable <stable@kernel.org>
+Link: https://patch.msgid.link/b440f177-f0b8-4d5a-8f7b-10855d4424ee@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/unusual_devs.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -938,7 +938,7 @@ UNUSUAL_DEV( 0x05e3, 0x0723, 0x9451, 0x
+ UNUSUAL_DEV( 0x0603, 0x8611, 0x0000, 0xffff,
+ "Novatek",
+ "NTK96550-based camera",
+- USB_SC_SCSI, USB_PR_BULK, NULL,
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BULK_IGNORE_TAG ),
+
+ /*
--- /dev/null
+From b59d4fda7e7d0aff1043a7f742487cb829f5aac1 Mon Sep 17 00:00:00 2001
+From: Tianchu Chen <flynnnchen@tencent.com>
+Date: Sun, 16 Nov 2025 12:46:18 +0800
+Subject: usb: storage: sddr55: Reject out-of-bound new_pba
+
+From: Tianchu Chen <flynnnchen@tencent.com>
+
+commit b59d4fda7e7d0aff1043a7f742487cb829f5aac1 upstream.
+
+Discovered by Atuin - Automated Vulnerability Discovery Engine.
+
+new_pba comes from the status packet returned after each write.
+A bogus device could report values beyond the block count derived
+from info->capacity, letting the driver walk off the end of
+pba_to_lba[] and corrupt heap memory.
+
+Reject PBAs that exceed the computed block count and fail the
+transfer so we avoid touching out-of-range mapping entries.
+
+Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
+Cc: stable <stable@kernel.org>
+Link: https://patch.msgid.link/B2DC73A3EE1E3A1D+202511161322001664687@tencent.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/sddr55.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/usb/storage/sddr55.c
++++ b/drivers/usb/storage/sddr55.c
+@@ -469,6 +469,12 @@ static int sddr55_write_data(struct us_d
+ new_pba = (status[3] + (status[4] << 8) + (status[5] << 16))
+ >> info->blockshift;
+
++ /* check if device-reported new_pba is out of range */
++ if (new_pba >= (info->capacity >> (info->blockshift + info->pageshift))) {
++ result = USB_STOR_TRANSPORT_FAILED;
++ goto leave;
++ }
++
+ /* check status for error */
+ if (status[0] == 0xff && status[1] == 0x4) {
+ info->pba_to_lba[new_pba] = BAD_BLOCK;
--- /dev/null
+From 26d56a9fcb2014b99e654127960aa0a48a391e3c Mon Sep 17 00:00:00 2001
+From: Owen Gu <guhuinan@xiaomi.com>
+Date: Thu, 20 Nov 2025 20:33:36 +0800
+Subject: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer
+
+From: Owen Gu <guhuinan@xiaomi.com>
+
+commit 26d56a9fcb2014b99e654127960aa0a48a391e3c upstream.
+
+When a UAS device is unplugged during data transfer, there is
+a probability of a system panic occurring. The root cause is
+an access to an invalid memory address during URB callback handling.
+Specifically, this happens when the dma_direct_unmap_sg() function
+is called within the usb_hcd_unmap_urb_for_dma() interface, but the
+sg->dma_address field is 0 and the sg data structure has already been
+freed.
+
+The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()
+in uas.c, using the uas_submit_urbs() function to submit requests to USB.
+Within the uas_submit_urbs() implementation, three URBs (sense_urb,
+data_urb, and cmd_urb) are sequentially submitted. Device removal may
+occur at any point during uas_submit_urbs execution, which may result
+in URB submission failure. However, some URBs might have been successfully
+submitted before the failure, and uas_submit_urbs will return the -ENODEV
+error code in this case. The current error handling directly calls
+scsi_done(). In the SCSI driver, this eventually triggers scsi_complete()
+to invoke scsi_end_request() for releasing the sgtable. The successfully
+submitted URBs, when being unlinked to giveback, call
+usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg
+unmapping operations since the sg data structure has already been freed.
+
+This patch modifies the error condition check in the uas_submit_urbs()
+function. When a UAS device is removed but one or more URBs have already
+been successfully submitted to USB, it avoids immediately invoking
+scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully
+submitted URBs is completed before devinfo->resetting being set, then
+the scsi_done() function will be called within uas_try_complete() after
+all pending URB operations are finalized. Otherwise, the scsi_done()
+function will be called within uas_zap_pending(), which is executed after
+usb_kill_anchored_urbs().
+
+The error handling only takes effect when uas_queuecommand_lck() calls
+uas_submit_urbs() and returns the error value -ENODEV . In this case,
+the device is disconnected, and the flow proceeds to uas_disconnect(),
+where uas_zap_pending() is invoked to call uas_try_complete().
+
+Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Yu Chen <chenyu45@xiaomi.com>
+Signed-off-by: Owen Gu <guhuinan@xiaomi.com>
+Acked-by: Oliver Neukum <oneukum@suse.com>
+Link: https://patch.msgid.link/20251120123336.3328-1-guhuinan@xiaomi.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/uas.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/usb/storage/uas.c
++++ b/drivers/usb/storage/uas.c
+@@ -697,6 +697,10 @@ static int uas_queuecommand_lck(struct s
+ * of queueing, no matter how fatal the error
+ */
+ if (err == -ENODEV) {
++ if (cmdinfo->state & (COMMAND_INFLIGHT | DATA_IN_URB_INFLIGHT |
++ DATA_OUT_URB_INFLIGHT))
++ goto out;
++
+ set_host_byte(cmnd, DID_NO_CONNECT);
+ scsi_done(cmnd);
+ goto zombie;
+@@ -710,6 +714,7 @@ static int uas_queuecommand_lck(struct s
+ uas_add_work(cmnd);
+ }
+
++out:
+ devinfo->cmnd[idx] = cmnd;
+ zombie:
+ spin_unlock_irqrestore(&devinfo->lock, flags);
--- /dev/null
+From f6bb3b67be9af0cfb90075c60850b6af5338a508 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 7 Nov 2025 18:28:17 +0200
+Subject: xhci: dbgtty: Fix data corruption when transmitting data form DbC to host
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit f6bb3b67be9af0cfb90075c60850b6af5338a508 upstream.
+
+Data read from a DbC device may be corrupted due to a race between
+ongoing write and write request completion handler both queuing new
+transfer blocks (TRBs) if there are remining data in the kfifo.
+
+TRBs may be in incorrct order compared to the data in the kfifo.
+
+Driver fails to keep lock between reading data from kfifo into a
+dbc request buffer, and queuing the request to the transfer ring.
+
+This allows completed request to re-queue itself in the middle of
+an ongoing transfer loop, forcing itself between a kfifo read and
+request TRB write of another request
+
+cpu0 cpu1 (re-queue completed req2)
+
+lock(port_lock)
+dbc_start_tx()
+kfifo_out(fifo, req1->buffer)
+unlock(port_lock)
+ lock(port_lock)
+ dbc_write_complete(req2)
+ dbc_start_tx()
+ kfifo_out(fifo, req2->buffer)
+ unlock(port_lock)
+ lock(port_lock)
+ req2->trb = ring->enqueue;
+ ring->enqueue++
+ unlock(port_lock)
+lock(port_lock)
+req1->trb = ring->enqueue;
+ring->enqueue++
+unlock(port_lock)
+
+In the above scenario a kfifo containing "12345678" would read "1234" to
+req1 and "5678" to req2, but req2 is queued before req1 leading to
+data being transmitted as "56781234"
+
+Solve this by adding a flag that prevents starting a new tx if we
+are already mid dbc_start_tx() during the unlocked part.
+
+The already running dbc_do_start_tx() will make sure the newly completed
+request gets re-queued as it is added to the request write_pool while
+holding the lock.
+
+Cc: stable@vger.kernel.org
+Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
+Tested-by: Łukasz Bartosik <ukaszb@chromium.org>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://patch.msgid.link/20251107162819.1362579-3-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-dbgcap.h | 1 +
+ drivers/usb/host/xhci-dbgtty.c | 17 ++++++++++++++++-
+ 2 files changed, 17 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-dbgcap.h
++++ b/drivers/usb/host/xhci-dbgcap.h
+@@ -113,6 +113,7 @@ struct dbc_port {
+ unsigned int tx_boundary;
+
+ bool registered;
++ bool tx_running;
+ };
+
+ struct dbc_driver {
+--- a/drivers/usb/host/xhci-dbgtty.c
++++ b/drivers/usb/host/xhci-dbgtty.c
+@@ -47,7 +47,7 @@ dbc_kfifo_to_req(struct dbc_port *port,
+ return len;
+ }
+
+-static int dbc_start_tx(struct dbc_port *port)
++static int dbc_do_start_tx(struct dbc_port *port)
+ __releases(&port->port_lock)
+ __acquires(&port->port_lock)
+ {
+@@ -57,6 +57,8 @@ static int dbc_start_tx(struct dbc_port
+ bool do_tty_wake = false;
+ struct list_head *pool = &port->write_pool;
+
++ port->tx_running = true;
++
+ while (!list_empty(pool)) {
+ req = list_entry(pool->next, struct dbc_request, list_pool);
+ len = dbc_kfifo_to_req(port, req->buf);
+@@ -77,12 +79,25 @@ static int dbc_start_tx(struct dbc_port
+ }
+ }
+
++ port->tx_running = false;
++
+ if (do_tty_wake && port->port.tty)
+ tty_wakeup(port->port.tty);
+
+ return status;
+ }
+
++/* must be called with port->port_lock held */
++static int dbc_start_tx(struct dbc_port *port)
++{
++ lockdep_assert_held(&port->port_lock);
++
++ if (port->tx_running)
++ return -EBUSY;
++
++ return dbc_do_start_tx(port);
++}
++
+ static void dbc_start_rx(struct dbc_port *port)
+ __releases(&port->port_lock)
+ __acquires(&port->port_lock)
--- /dev/null
+From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb@chromium.org>
+Date: Wed, 19 Nov 2025 21:29:09 +0000
+Subject: xhci: dbgtty: fix device unregister
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Łukasz Bartosik <ukaszb@chromium.org>
+
+commit 1f73b8b56cf35de29a433aee7bfff26cea98be3f upstream.
+
+When DbC is disconnected then xhci_dbc_tty_unregister_device()
+is called. However if there is any user space process blocked
+on write to DbC terminal device then it will never be signalled
+and thus stay blocked indifinitely.
+
+This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device().
+The tty_vhangup() wakes up any blocked writers and causes subsequent
+write attempts to DbC terminal device to fail.
+
+Cc: stable <stable@kernel.org>
+Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
+Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org>
+Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-dbgtty.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/usb/host/xhci-dbgtty.c
++++ b/drivers/usb/host/xhci-dbgtty.c
+@@ -519,6 +519,12 @@ static void xhci_dbc_tty_unregister_devi
+
+ if (!port->registered)
+ return;
++ /*
++ * Hang up the TTY. This wakes up any blocked
++ * writers and causes subsequent writes to fail.
++ */
++ tty_vhangup(port->port.tty);
++
+ tty_unregister_device(dbc_tty_driver, port->minor);
+ xhci_dbc_tty_exit_port(port);
+ port->registered = false;
projects / thirdparty / kernel / stable-queue.git / commitdiff
