Import Source
https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-72871.json
JSON Data
https://api.test.osv.dev/v1/vulns/AZL-72871
Upstream
Published
2025-12-22T17:16:00Z
Modified
2026-04-01T05:22:13.356247Z
Summary
CVE-2025-68331 affecting package kernel for versions less than 6.6.119.3-1
Details

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().

References

Affected packages

Azure Linux:3 / kernel

Package

Name
kernel
Purl
pkg:rpm/azure-linux/kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.6.119.3-1

Database specific

source
"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-72871.json"