CVE-2025-68331

In the Linux kernel, the following vulnerability has been resolved:

usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer

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 dmadirectunmapsg() function is called within the usbhcdunmapurbfordma() 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 uasqueuecommandlck() in uas.c, using the uassubmiturbs() function to submit requests to USB. Within the uassubmiturbs() implementation, three URBs (senseurb, dataurb, and cmdurb) are sequentially submitted. Device removal may occur at any point during uassubmiturbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uassubmiturbs will return the -ENODEV error code in this case. The current error handling directly calls scsidone(). In the SCSI driver, this eventually triggers scsicomplete() to invoke scsiendrequest() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usbhcdunmapurbfordma() 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 uassubmiturbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsidone() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsidone() function will be called within uastrycomplete() after all pending URB operations are finalized. Otherwise, the scsidone() function will be called within uaszappending(), which is executed after usbkillanchoredurbs().

The error handling only takes effect when uasqueuecommandlck() calls uassubmiturbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uasdisconnect(), where uaszappending() is invoked to call uastry_complete().