In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: clear forceRM when issuing EndTransfer
The forceRM bit of the DEPCMD register controls the behavior of the
EndTransfer command used to stop an active transfer. Older DWC3
programming guide revisions recommended setting forceRM=1 when
issuing EndTransfer. Newer programming guide revisions recommend
issuing EndTransfer with forceRM cleared.
With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer
aborted through the ep_dequeue path was observed to remain active
after EndTransfer completion. A subsequent StartTransfer issued on the
same endpoint triggered writes associated with the aborted transfer.
This resulted in an SMMU fault because the transfer buffer had already
been unmapped during EndTransfer command-completion cleanup.
Using forceRM=0 eliminates the issue. Although older DWC3 programming
guide revisions recommended setting forceRM=1, no issues are known
from using forceRM=0. Clear forceRM when issuing EndTransfer to provide
consistent EndTransfer behavior and align with newer programming guide
recommendations.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The documented trigger is dwc3_gadget_ep_dequeue(), reached from FunctionFS via usb_ep_dequeue() on ordinary local syscalls (interrupted read, aio_cancel, close, FUNCTIONFS_DMABUF_DETACH) rather than USB host packet parsing; this matches AV:L used for other f_fs/dwc3 EndXfer bugs (CVE-2024-36977, CVE-2024-36894).
AC:L - On affected DWC_usb31 controllers the attacker deterministically queues a request, dequeues it so EndTransfer runs with forceRM=1, then queues again so StartTransfer replays DMA to the already-unmapped buffer; no uncontrolled race is involved, and v2.00a/v2.10a hardware is common on Qualcomm phones and embedded boards.
PR:L - FunctionFS endpoint nodes are routinely delegated to unprivileged gadget daemons (adbd/shell, MTP) via uid=/gid=/fmode=; queue, cancel, and re-queue are ordinary file operations and the dequeue path performs no capability check.
UI:N - The attacking process performs the queue, dequeue, and re-queue itself; a USB cable being attached is an ambient condition of phones, kiosks, and embedded gadgets, not a separate victim action the attacker must induce.
S:U - Stale controller DMA targets the transfer buffer the gadget had already mapped in the same kernel; this is not a VM escape or IOMMU-domain bypass, and an SMMU, when present, faults the access rather than being circumvented.
C:H - The same EndTransfer forceRM mishandling applies to IN endpoints, so after unmap the still-active transfer can DMA-read reused pages onto the USB bus; per kernel UAF guidance this memory-corruption primitive also yields kernel disclosure once backing pages are reallocated.
I:H - The issue was reproduced as stale DMA writes on an OUT bulk endpoint into a buffer already unmapped during EndTransfer completion cleanup, so leftover or host-supplied data is written into reallocated kernel pages, a DMA use-after-free write primitive suitable for control-flow hijacking.
A:H - The commit reports an SMMU fault when the controller accesses the already-unmapped transfer buffer, which panics or wedges the USB/IOMMU path; without an IOMMU the same DMA use-after-free likewise oopses or panics the kernel.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The documented trigger is dwc3_gadget_ep_dequeue(), reached from FunctionFS via usb_ep_dequeue() on ordinary local syscalls (interrupted read, aio_cancel, close, FUNCTIONFS_DMABUF_DETACH) rather than USB host packet parsing; this matches AV:L used for other f_fs/dwc3 EndXfer bugs (CVE-2024-36977, CVE-2024-36894).
AC:L - On affected DWC_usb31 controllers the attacker deterministically queues a request, dequeues it so EndTransfer runs with forceRM=1, then queues again so StartTransfer replays DMA to the already-unmapped buffer; no uncontrolled race is involved, and v2.00a/v2.10a hardware is common on Qualcomm phones and embedded boards.
PR:L - FunctionFS endpoint nodes are routinely delegated to unprivileged gadget daemons (adbd/shell, MTP) via uid=/gid=/fmode=; queue, cancel, and re-queue are ordinary file operations and the dequeue path performs no capability check.
UI:N - The attacking process performs the queue, dequeue, and re-queue itself; a USB cable being attached is an ambient condition of phones, kiosks, and embedded gadgets, not a separate victim action the attacker must induce.
S:U - Stale controller DMA targets the transfer buffer the gadget had already mapped in the same kernel; this is not a VM escape or IOMMU-domain bypass, and an SMMU, when present, faults the access rather than being circumvented.
C:H - The same EndTransfer forceRM mishandling applies to IN endpoints, so after unmap the still-active transfer can DMA-read reused pages onto the USB bus; per kernel UAF guidance this memory-corruption primitive also yields kernel disclosure once backing pages are reallocated.
I:H - The issue was reproduced as stale DMA writes on an OUT bulk endpoint into a buffer already unmapped during EndTransfer completion cleanup, so leftover or host-supplied data is written into reallocated kernel pages, a DMA use-after-free write primitive suitable for control-flow hijacking.
A:H - The commit reports an SMMU fault when the controller accesses the already-unmapped transfer buffer, which panics or wedges the USB/IOMMU path; without an IOMMU the same DMA use-after-free likewise oopses or panics the kernel.
CVSS 3.1