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.
- Configuration
When issuing EndTransfer, clear the forceRM bit (forceRM=0) to avoid the SMMU fault and to ensure consistent EndTransfer behavior.
Linux kernel dwc3 (USB) forceRM (DEPCMD register) = 0 - Configuration
If using forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, ensure the EndTransfer behavior clears forceRM as required (clear forceRM when issuing EndTransfer) so transfers aborted via ep_dequeue do not remain active after EndTransfer completion.
Linux kernel dwc3 (USB) forceRM (DEPCMD register) = 1
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.