CVE-2026-90030: usb: dwc3: clear forceRM when issuing EndTransfer
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 DWCusb31 v2.00a and v2.10a controllers, a transfer aborted through the epdequeue 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.159.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Clear forceRM when issuing EndTransfer; issue EndTransfer with forceRM cleared.
DWC3 DEPCMD EndTransfer forceRM = 0
Event History
Frequently Asked Questions
Which systems are specifically known to exhibit the faulty behavior?
The issue was observed on DWC_usb31 v2.00a and v2.10a controllers. It occurs when an active transfer is aborted through the ep_dequeue path and another transfer is started on the same endpoint.
What is the practical failure mode?
The aborted transfer can remain active after EndTransfer completes. Starting a new transfer on that endpoint can then cause writes for the old transfer after its buffer has been unmapped, resulting in an SMMU fault.
Is there a configuration-based mitigation if the update cannot be applied immediately?
The documented mitigation is to issue EndTransfer with forceRM cleared (forceRM=0). No issues are known from using forceRM=0, including on controllers covered by older programming-guide recommendations that specified forceRM=1.