CVE-2026-90030 in Linux
Summary
by MITRE • 09/17/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for the DesignWare USB 3 (dwc3) controller contains a logic flaw in how it handles the termination of active data transfers, specifically regarding the configuration of the forceRM bit within the DEPCMD register. This hardware control bit dictates whether an EndTransfer command should forcefully reset the endpoint state or allow for a graceful teardown. Historically, earlier revisions of the DWC3 programming guide advised setting this bit to one when issuing an EndTransfer operation. However, subsequent updates to these technical specifications clarified that clearing this bit is the correct procedure for ensuring proper hardware behavior during transfer termination. The driver had not been updated to reflect this change in best practices, leading to inconsistent handling of endpoint state across different controller revisions and operational scenarios.
The vulnerability manifests primarily on DWC_usb31 controllers with silicon versions 2.00a and 2.10a when a transfer is aborted via the ep_dequeue path, which typically occurs during error recovery or connection teardown sequences. When forceRM remains set to one in these specific hardware revisions, the EndTransfer command fails to properly halt the active data movement. Consequently, even after the controller reports that the EndTransfer operation has completed successfully, the underlying transfer engine continues to process data associated with the now-aborted request. This state desynchronization means the driver proceeds with cleanup routines under the false assumption that all hardware activity related to that endpoint has ceased.
The operational impact of this flaw is severe and involves memory safety violations due to a race condition between hardware activity and software resource management. During the EndTransfer completion handler, the kernel unmaps the DMA buffers associated with the transfer to free up system resources and ensure security isolation. However, because the forceRM flag causes the controller to ignore the stop command on affected silicon versions, the device continues to perform Direct Memory Access (DMA) writes into these memory regions after they have been unmapped from the I/O memory map. This results in an System Management Unit (SMMU) fault as the hardware attempts to access physical addresses that are no longer mapped or protected by the current translation tables. Such faults can lead to system instability, kernel panics, or potential data corruption depending on how the SMMU handles the unauthorized access attempt.
From a vulnerability classification perspective, this issue aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Separate Threads, as it involves a race condition between hardware state and software cleanup logic. It also relates to CWE-401, Missing Release of Memory after Effective Lifetime, in the context that resources are released while still being actively used by external agents. In terms of attack vectors, this could potentially be leveraged for Denial of Service (DoS) attacks if an attacker can trigger repeated endpoint dequeues on affected hardware, causing persistent SMMU faults and system crashes. It may also touch upon CWE-787, Out-of-bounds Write, as the DMA operations occur into unmapped or freed memory regions, although the primary manifestation is a fault rather than arbitrary code execution in this specific context.
The mitigation for this vulnerability involves updating the dwc3 driver to clear the forceRM bit when issuing EndTransfer commands, thereby aligning with newer programming guide recommendations and ensuring consistent behavior across all supported DWC3 silicon revisions. This change ensures that the hardware properly halts active transfers before the software proceeds with buffer unmapping and resource cleanup. By enforcing this correct sequence of operations, the race condition is eliminated, preventing unauthorized DMA accesses to freed memory regions. System administrators should apply kernel updates containing this fix immediately on systems utilizing affected DWC3 controllers to restore stability and prevent potential denial-of-service conditions caused by hardware faults during USB device disconnection or error recovery scenarios.