[CVE-2026-90030][MODERATE 7.0] usb: dwc3: clear forceRM when issuing EndTransfer

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-90030
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: usb: dwc3: clear forceRM when issuing EndTransfer
Commit: 0afe5c31612de3d18cc6d16e616da4a48ba1e5a2
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0afe5c31612de3d18cc6d16e616da4a48ba1e5a2
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90030
Analysis date: Wed, 16 Sep 2026 14:01:48 -0400
ActionableScore: 5
ActionableScore lower bound: 3
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-90030 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90030

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-90030	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-90030 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H';*CWE-416;*CWE-664;*CWE-787;Other CVSS 'AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '6.4';DESCR 'An EndTransfer state handling flaw in the DWC3 USB gadget driver can leave an aborted transfer active when forceRM is set on DWC_usb31 v2.00a and v2.10a controllers. After ep_dequeue cleanup has unmapped the transfer buffer, a later StartTransfer on the same endpoint may still cause controller writes associated with the aborted transfer. The observed result is an SMMU fault and kernel denial of service, and on systems without effective DMA isolation the same pattern is a plausible DMA use after unmap memory-corruption candidate. For the CVSS the PR:N is used because a USB host does not need credentials on the gadget device, but physical USB attachment is required and this is not IP network reachable. Impact is at least DoS and the paranoid score keeps C:H/I:H/A:H for manual-review sensitivity because the controller may write after the buffer lifetime ended.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 4)	YES	USB SIMPLEFIX LINUS TEST 	YES	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=5
ActionableScoreLower=3
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 3
* Conservative score: 3
* Raw paranoid score: 5
* Paranoid score: 5
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

No floor or cap was applied.

2. Signal breakdown

Conservative signals:

* +2 Real UAF / lifetime violation. EndTransfer completion cleanup unmaps the transfer buffer, but the controller may keep the aborted transfer active and later write to storage whose DMA lifetime has ended.
* +1 Constrained kernel buffer overwrite. The write is a real post-unmap DMA write, but target and payload control are constrained by the DWC3 transfer state.
* +1 Reliable kernel crash / strong DoS. The observed consequence is an SMMU fault.
* +1 Firmware or device mediated external influence. The vulnerable behavior is reached through USB controller and gadget endpoint state, not a local syscall-only path.
* -2 Physical-only and hardware-specific exposure. The issue is tied to USB gadget operation on DWC_usb31 v2.00a and v2.10a controllers and requires USB-host-side interaction or equivalent device topology.

Paranoid additional / adjusted signals:

* +1 Weak exploitation concern. On systems without effective DMA isolation, a post-unmap DMA write can become a plausible memory-corruption candidate if the backing memory is reused before the stale hardware write completes.
* -1 Exposure remains constrained by specific DWC3 hardware and gadget mode, but not treated as fully rare in the paranoid score because affected controllers are plausible in embedded/mobile deployments.

Important non-awarded signals:

* Controlled reclaim is not demonstrated.
* Arbitrary or directed kernel write is not demonstrated.
* Callback, function pointer, credential, or security-object overwrite is not demonstrated.
* Network reachability is not established. This is USB physical/topology reachability, not IP network reachability.
* Extra Availability was not awarded because the SMMU fault and crash are the same DoS consequence.
* Concrete repeated release/refcount was not awarded because this is fixed async DMA stale storage, not a second put/release on the same dangling object.

3. Reachability analysis

The attacker model is an external USB host or an entity able to drive the USB gadget endpoint behavior on an already configured vulnerable device. Host administrator privileges on the gadget device are not required for the external USB host role, so HostAdminRequired=NO. This is not namespace-scoped and does not involve CAP_NET_ADMIN or user namespaces.

The complete trigger likely depends on a deployed USB gadget function, endpoint transfers, an abort through ep_dequeue, and a subsequent StartTransfer on the same endpoint. Prior device configuration may exist in the product, but the supplied evidence does not require the attacker to be host root. The exposure is constrained by DWC_usb31 v2.00a/v2.10a hardware and by physical or topology-level USB access. Timing/order matters, but this is mainly a device state sequencing issue rather than a pure hard race.

4. Primitive and severity interpretation

The exact primitive is DMA use-after-unmap: an aborted transfer can remain active after EndTransfer completion, and later controller writes can target a buffer already unmapped during cleanup. This is fixed stale storage rather than an active structured object UAF. It is not a concrete repeated refcount or double-release case.

Demonstrated consequence is SMMU fault and DoS. Speculative but technically defensible consequence is memory corruption on platforms without effective DMA isolation or where the stale DMA target is reused. Because the patch establishes a real post-lifetime hardware write, this is CLASS_B rather than crash-only CLASS_C. ImportantCandidate=YES because the DMA write-after-unmap primitive has unresolved impact beyond a simple NULL dereference or WARN. AutoDowngradeAllowed=NO because automatic closure would lose a concrete kernel DMA lifetime-corruption primitive that requires manual review.

5. One-sentence report phrase

A DWC3 USB gadget EndTransfer handling flaw can leave an aborted transfer active after its buffer is unmapped, allowing later controller writes to stale DMA storage and causing at least an SMMU fault DoS with possible memory corruption on systems lacking effective DMA isolation.

6. Manual review recommendation

MANUAL CHECK REQUIRED

The issue is hardware-specific but establishes a real DMA use-after-unmap primitive, and the difference between SMMU-contained DoS and broader memory corruption depends on platform DMA isolation and memory reuse behavior.

7. Call-site confidence

Call-site confidence: medium

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: usb: dwc3: clear forceRM when issuing EndTransfer
Commit: 0afe5c31612de3d18cc6d16e616da4a48ba1e5a2
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0afe5c31612de3d18cc6d16e616da4a48ba1e5a2

Commit description:

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.

Fixes: 1e43c86 ("usb: dwc3: core: Add DWC31 version 2.00a controller")
Cc: stable <stable@kernel.org>
Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://patch.msgid.link/20260813151456.867008-1-elson.serrao@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  drivers/usb/dwc3/ep0.c
  drivers/usb/dwc3/gadget.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0afe5c31612de3d18cc6d16e616da4a48ba1e5a2

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-90030 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90030

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 6.4

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 3
  Paranoid ActionableScore: 5

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).