Look up another CVE · open CVE-2026-90030 in the interactive tracker
CVE-2026-90030
usb: dwc3: clear forceRM when issuing EndTransfer
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/usb. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90030 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/usb/dwc3/ep0.c
drivers/usb/dwc3/gadget.c
- What this is
- DESIGNWARE USB3 DRD IP DRIVERMAINTAINERS section matched on drivers/usb/dwc3/ · linux-usb@vger.kernel.org · Maintained
- Kernel module
- dwc3
Check it on the machine
grep -wE 'CONFIG_OF|CONFIG_PCI|CONFIG_USB|CONFIG_USB_DWC3|CONFIG_USB_GADGET|CONFIG_USB_PHY|CONFIG_USB_SUPPORT' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w dwc3Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_OF, CONFIG_PCI, CONFIG_USB, CONFIG_USB_DWC3, CONFIG_USB_GADGET, CONFIG_USB_PHY, CONFIG_USB_SUPPORT
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/usb
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.9 | 6.12.112 | 9f1e57c484f9 |
| 6.9 | 6.18.51 | 0afe5c31612d |
| 6.9 | 7.2.5 | e01408ee52fe |
| 6.9 | 7.3 | b58e6200450d |
| 6.6.37 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- 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:LAttack complexity, low
- 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:LPrivileges required, low
- 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:NUser interaction, none
- 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:UScope, unchanged
- 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:HConfidentiality impact, high
- 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:HIntegrity impact, high
- 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:HAvailability impact, high
- 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.