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 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().
Affected versions
Linux kernel versions
5.10
and later are affected. Fixed in
5.10.247,
5.15.197,
6.1.159,
6.6.119,
6.12.61,
6.17.11,
6.18
and their respective stable series.
References
The following references provide additional information about CVE-2025-68331 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.
-
PatchKernel patch commithttps://git.kernel.org/stable/c/26d56a9fcb2014b99e654127960aa0a48a391e3c
-
PatchKernel patch commithttps://git.kernel.org/stable/c/2b90a8131c83f6f2be69397d2b7d14d217d95d2f
-
PatchKernel patch commithttps://git.kernel.org/stable/c/426edbfc88b22601ea34a441a469092e7b301c52
Frequently asked questions
-
What is CVE-2025-68331?
CVE-2025-68331 is a unscored severity Linux kernel vulnerability . It affects Linux kernel versions from 5.10 onward and has been patched in 5.10.247, 5.15.197, 6.1.159 and others. CVE-2025-68331 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.
-
Is there a patch available for CVE-2025-68331?
Yes — CVE-2025-68331 has been patched. Fixed versions include 5.10.247, 5.15.197, 6.1.159 and others. If you are running Linux kernel 5.10 or later up to the fix versions, apply the relevant patch for your kernel branch.
-
Is CVE-2025-68331 actively exploited?
No — CVE-2025-68331 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.