CVE-2025-68331
Unknown Unknown - Not Provided
Use-After-Free Vulnerability in Linux USB UAS Causes System Panic

Publication date: 2025-12-22

Last updated on: 2025-12-22

Assigner: kernel.org

Description
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().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-22
Last Modified
2025-12-22
Generated
2026-05-07
AI Q&A
2025-12-23
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's USB Attached SCSI (UAS) driver. When a UAS device is unplugged during an ongoing data transfer, the system may panic due to an invalid memory access. Specifically, the issue arises because the driver attempts to unmap DMA memory for USB Request Blocks (URBs) after the associated scatter-gather (sg) data structure has already been freed, leading to access of a zero dma_address field. This happens during error handling when some URBs have been submitted successfully but the device is removed before all URBs complete. The patch changes the error handling to delay completion callbacks until all pending URBs are finalized, preventing the invalid memory access and system panic.


How can this vulnerability impact me? :

This vulnerability can cause a system panic (crash) if a UAS device is unplugged during data transfer. This can lead to loss of data, system instability, and potential downtime as the kernel crashes and requires a reboot. It affects system reliability and availability when using USB Attached SCSI devices.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version that includes the patch fixing the urb unmapping issue in the uas driver. This patch modifies error handling in uas_submit_urbs() to prevent system panic when a UAS device is removed during ongoing data transfer. Avoid unplugging UAS devices during active data transfers until the patch is applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart