# CVE-2025-68331: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer

> A local attacker with physical access can cause a system panic by unplugging a USB device during data transfer due to a use-after-free bug in the UAS driver.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 22 Dec 2025
- **Updated:** 11 May 2026
- **Also known as:** AZL-72871, BELL-CVE-2025-68331, DEBIAN-CVE-2025-68331, GHSA-cmqf-qgg2-7p77, ROOT-OS-DEBIAN-12-CVE-2025-68331, ROOT-OS-DEBIAN-13-CVE-2025-68331, ROOT-OS-UBUNTU-2204-CVE-2025-68331, ROOT-OS-UBUNTU-2404-CVE-2025-68331, UBUNTU-CVE-2025-68331

## What is CVE-2025-68331?

CVE-2025-68331 is an use after free vulnerability in Linux, published on 22 Dec 2025. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.

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

## Which versions are affected by CVE-2025-68331?


## How do I fix CVE-2025-68331?

Apply the vendor's patch.

## Is CVE-2025-68331 being exploited?

There is no known exploitation of CVE-2025-68331 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2025-68331 and fix it if it is affected.

What it is: CVE-2025-68331 is an use after free vulnerability in Linux, published on 22 Dec 2025. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of CVE-2025-68331 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2025-68331/ (Markdown: https://insights.sbomify.com/CVE-2025-68331/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2025-68331
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-68331
- OSV: https://osv.dev/vulnerability/CVE-2025-68331

---
From sbomify Insights: https://insights.sbomify.com/CVE-2025-68331/
Summaries are generated and may contain mistakes; the official description above is the record.