The Linux kernel has received a targeted patch that closes a timing-related defect in the DWC3 USB gadget driver: a race in the dwc3_remove_requests paths that could allow USB requests to be freed while still in use, producing kernel crashes and instability across affected devices.
The affected component is the in-tree DWC3 USB gadget driver (drivers/usb/dwc3/gadget.c), a commonly used driver on many ARM-based SoCs and embedded platforms that implement USB device (gadget) functionality. The defect was assigned CVE-2025-68287 and was entered into public vulnerability databases following upstream kernel disclosure and a small, surgical patch submitted to the mainline/stable kernel trees. This article explains the technical root cause, the exact call paths involved, how the upstream patch addresses the issue, which systems and kernel trees are affected, and practical mitigation and remediation advice for system builders and administrators. Where possible, assertions are cross-referenced against multiple independent trackers and the upstream patch discussion to ensure accuracy.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
The affected component is the in-tree DWC3 USB gadget driver (drivers/usb/dwc3/gadget.c), a commonly used driver on many ARM-based SoCs and embedded platforms that implement USB device (gadget) functionality. The defect was assigned CVE-2025-68287 and was entered into public vulnerability databases following upstream kernel disclosure and a small, surgical patch submitted to the mainline/stable kernel trees. This article explains the technical root cause, the exact call paths involved, how the upstream patch addresses the issue, which systems and kernel trees are affected, and practical mitigation and remediation advice for system builders and administrators. Where possible, assertions are cross-referenced against multiple independent trackers and the upstream patch discussion to ensure accuracy.Overview: what the bug is and why it matters
At its core, CVE-2025-68287 is a classic race condition resulting in a use‑after‑free: several asynchronous and partially unsynchronized code paths could call dwc3_remove_requests concurrently, allowing one path to free request structures while another path still expected them to be valid. When that happens, the kernel dereferences freed memory and typically triggers KASAN reports, WARN_ONs, stack traces, or kernel panics — in short, availability and reliability problems for devices using the driver. Multiple independent vulnerability trackers and vendor advisories characterize the primary impact as an availability/DoS class issue rather than an immediate remote-code-execution vector; transforming such a timing bug into a reliable escalation or RCE would require additional, platform-specific conditions. Still, in embedded devices, appliances, and mobile platforms where gadget code is widely used, an unexpected kernel crash is a high-priority reliability problem.Technical anatomy: how the race happens
The three interacting call paths
Upstream analysis and the patch submission identify three distinct execution paths that can converge on dwc3_remove_requests, creating a narrow but real concurrency window:- Path 1 — USB reset handling: Initiated by dwc3_gadget_reset_interrupt, proceeding through dwc3_ep0_reset_state → dwc3_ep0_stall_and_restart → dwc3_ep0_out_start → dwc3_remove_requests → dwc3_gadget_del_and_unmap_request.
- Path 2 — Stop active transfers on reset: Also coming from dwc3_gadget_reset_interrupt, but routed through dwc3_stop_active_transfers → dwc3_remove_requests → dwc3_gadget_del_and_unmap_request.
- Path 3 — Asynchronous function unbind during adb/root workflows: Triggered by higher-level gadget unbind sequences (for example gserial_disconnect invoked during adb root operations), which call usb_ep_disable → dwc3_gadget_ep_disable → dwc3_remove_requests with an -ESHUTDOWN status. Path 3 runs asynchronously relative to Paths 1 and 2 and lacks the necessary synchronization guarantees.
Why this is subtle but real
A gadget driver commonly relies on a mix of completion callbacks, endpoint state transitions, and hardware commands (ENDXFER) to coordinate request lifetimes. The DWC3 driver historically used fast paths to return or remove requests in different contexts; the bug arose because one of those contexts (the function unbind disable path) could proceed to deallocate requests without waiting for the reset/interrupt-driven paths to finish their work. The timing window is small, platform-dependent, and more likely to trigger under high concurrency or during device debug/rebind loops (for example when adb cycles USB gadget functions). Cross-checking with independent vulnerability feeds confirms the same high‑level anatomy and reproducer patterns described above, indicating the upstream root cause analysis is consistent across multiple vendors and aggregators.The upstream fix: what changed in the driver
The patch submitted upstream (authored by Manish Nagar and merged into stable trees) takes a conservative, correctness-first approach:- Make the endpoint disable path behave synchronously with respect to pending transfers: ensure an ENDXFER is issued to stop the endpoint and that all pending requests are returned (via dwc3_gadget_giveback before the driver frees request structures.
- Add a check for request completion and skip processing for requests that are already completed. The patch also sets or preserves a request status for EP0 while it is queued, avoiding ambiguous ownership during reset/unbind transitions.
- Rework usb_ep_disable/ep_disable interactions so that gadget-level disconnect paths (for example gserial_disconnect will only free resources after the core DWC3 code has given back pending requests and executed the appropriate completion semantics.
Verification and commit references
Upstream stable commit references are listed in public CVE records and vendor advisories; NVD (and the OSV import) point to several kernel stable commits implementing the fix. Because some web mirrors or automated fetches can be blocked, administrators should verify by mapping the kernel tree commit IDs into their vendor kernel changelogs or by inspecting their distribution’s security advisory for the exact package-level backport.Affected kernels, distributions, and products
- Public vulnerability trackers and vendor advisories (Debian security tracker, SUSE pages, AWS ALAS and others) have ingested the CVE and mapped it into distribution advisories and package backports. Affected kernel series depend on whether the distribution has merged the upstream stable commits into their kernel package.
- The practical exposure list includes:
- Embedded images and OEM kernels shipping DWC3 gadget driver enabled by default (common on many ARM SoCs).
- Developer devices and phones using gadget features and run adb workflows that perform frequent bind/unbind (adb root and similar).
- Virtualization hosts that expose USB gadget endpoints to guests via passthrough or that maintain custom vendor kernels.
- Severity and scoring: Several trackers classify the issue at Important / CVSS ~7.0 in vendor mappings (reflecting a local/adjacent vector with high impact on availability), although scoring varies by vendor and depends on whether the kernel package is deployed with gadget code enabled. Administrators should treat the ranking as a priority for devices that use gadget functionality, but the precise CVSS mapping should be taken from each vendor’s advisory.
Exploitability: realistic risk model
- Attack vector: local or local-adjacent. The race is triggered by the intersection of reset handling and gadget unbind/disable paths; in many cases reproducing it requires either developer operations (adb sequences) or specific device behavior — this is not a remote unauthenticated network service bug in the usual sense.
- Impact: primarily availability (kernel oops, KASAN tracebacks, device resets, instability). There is no authoritative public proof-of-concept demonstrating reliable privilege escalation or remote code execution stemming from this single timing bug at disclosure time; public trackers emphasize DoS/crash as the practical consequence. Nonetheless, kernel use-after-free conditions can be theoretically valuable to skilled exploit developers if combined with heap grooming and other primitives, so defenders should not dismiss the long‑tail risk.
- Likelihood of weaponization: low-to-moderate in the wild for general desktop/server deployments, higher for targeted attacks against embedded platforms, appliances, or developer devices where gadget workflows are common. The presence of debugging tools (KASAN) or deterministic test harnesses can increase the reproducibility in lab environments.
Detection, forensic signals, and hunting
Effective detection focuses on kernel logs and reproducer patterns:- Look for kernel oopses and stack traces referencing DWC3 symbols such as dwc3_remove_requests, dwc3_gadget_ep_disable, dwc3_gadget_del_and_unmap_request, dwc3_gadget_reset_interrupt, and ep0 reset/stall functions. These will appear in dmesg or journalctl -k.
- KASAN-enabled builds will produce slab UAF reports that explicitly name the freed object and the code path; such traces are diagnostic and should be captured (save vmcore, dmesg, and KASAN logs).
- Repro steps seen in public discussion: repeated bind/unbind cycles (for example adb root workflows on devices that attach gadget functions) combined with device reset events are the most likely to trigger the race. If you can reproduce the crash in a controlled environment, collect a full kernel backtrace and link it to a git commit range to validate whether the fix is present in your kernel.
Mitigation and remediation
Immediate/short-term mitigations
- If gadget functionality is not required on a device or image, disable it: blacklist the DWC3 gadget module or disable gadget-related kernel config options and rebuild the kernel image. This removes the affected code path entirely and is a valid stop-gap for appliances that do not need device-mode USB.
- For devices under active development where adb cycles are frequent, avoid performing bind/unbind sequences while also inducing resets or other interrupt-heavy operations, until a patched kernel is installed. This reduces the window for the race to occur but is not a robust long-term fix.
- Where possible, run debug builds with KASAN and sanitizers in staging to detect and triage crashes during test cycles before rolling kernels into production. While KASAN is not a mitigation, it makes these races far easier to diagnose.
Long-term remediation
- Deploy a kernel that contains the upstream stable commits or a vendor backport implementing the dwc3 fix. Verify the fix by checking kernel changelogs or package changelogs for the patch.
- For embedded/OEM kernels, backport the exact upstream changes into the vendor kernel and validate across all board variants and device tree configurations; run soak tests that exercise gadget bind/unbind and reset events.
- Where third‑party vendor kernels are used (device manufacturers, appliance vendors), consult their security advisories for fixed package versions rather than attempting ad‑hoc kernel patching, unless you maintain a tested build pipeline that can validate the backport.
Vendor and ecosystem response
Multiple large distribution trackers and vendors have already mapped the CVE and are preparing or publishing fixes:- Debian and SUSE trackers show advisory entries and package mappings for kernels that include the upstream fix; Amazon Linux/ALAS, Red Hat, and other vendor pages are in various stages of advising status and backporting. Administrators must consult their distribution’s security advisory for package-level guidance.
- The upstream patch submission and discussion are visible on kernel mailing lists (patch thread and follow-ups), and the fix was merged into stable kernel trees as a small, low-regression change (drivers/usb/dwc3/gadget.c edits). That makes vendor backports straightforward in most cases, but OEM/embedded vendors should still validate hardware-specific interactions.
Practical checklist for administrators and integrators
- Inventory: Identify devices and kernels that build or load the DWC3 gadget driver. Prioritize devices that: (a) expose USB gadget functions in production, (b) run developer workflows that do frequent bind/unbind (adb), or (c) use vendor kernels with limited security support.
- Patch: Apply vendor-supplied kernel updates that include the upstream stable commits. If vendor packages are delayed, plan a validated backport into your tested kernel pipeline and stage rollouts to reduce operational risk.
- Monitor: Watch kernel logs for DWC3-related oopses; capture vmcore/KASAN traces when crashes occur. Use centralized logging and automation to detect repeated crashes indicative of the race.
- Defend in depth: Where immediate patching is impossible, mitigate by disabling gadget features when not in use, limiting who can attach or rebind functions, and restricting developer workflows that combine adb/unbind cycles with resets.
Strengths of the upstream fix — and remaining risks
The upstream remedy is commendable for being surgical and defensive. It:- Addresses the precise lifetime/synchronization gap without a broad refactor, reducing regression risk.
- Ensures endpoint disable semantics wait for pending requests to be given back to the function driver, closing the observed interleavings.
- Adds defensive request-completion checks that make the driver more robust to asynchronous unbinds.
- Vendor divergence: OEM or appliance kernels that have extensive vendor patches or custom USB stack changes may not receive timely backports. Inventory and vendor coordination remain necessary.
- Chaining risk: While this CVE’s disclosed effect is availability, kernel UAFs are conceptually useful primitives in complex exploit chains. Systems with local untrusted code execution (multi-tenant testbeds, CI runners, developer machines) should accelerate patching.
- Verification gap: Some commit links referenced by public CVE records point to git.kernel.org stable commits that may be blocked by mirrors or network filters; maintainers and integrators should validate by comparing commit IDs against vendor changelogs or by securing direct access to kernel.org from a network that permits it. If you cannot fetch raw commits, rely on vendor advisories and package changelogs for authoritative mapping.
Conclusion and actionable next steps
CVE-2025-68287 is a meaningful reliability vulnerability in the DWC3 USB gadget driver that was fixed upstream with a focused change to synchronize request removal and to defend against double‑free/use‑after‑free races arising from asynchronous unbind and reset interactions. The fix is intentionally minimal and suitable for downstream backports, but operators must still map upstream commits to their distribution or OEM kernel packages and deploy updates in a validated manner. Actionable priorities:- Inventory all systems that use the DWC3 gadget driver and tag those that are production-critical or developer-oriented.
- Apply vendor kernel updates that include the upstream fix as soon as they are available; for embedded/OEM kernels, plan validated backports and test across board variants.
- Temporarily restrict gadget bind/unbind cycles in production and disable gadget modules where not needed until patched kernels are in place.
- Monitor kernel logs for DWC3-related oopses and capture forensic traces (vmcore/KASAN) to speed triage if crashes appear.
Source: MSRC Security Update Guide - Microsoft Security Response Center
