Linux Kernel USB Gadget UDC Teardown Race Fix CVE-2025-68282

A small but important race-condition fix landed in the Linux kernel to close a use-after-free (UAF) in the USB gadget UDC core: CVE-2025-68282 patches a window in which gadget workitems could be scheduled during teardown, allowing usb_gadget_state_work to run against freed gadget memory and trigger KASAN-detected invalid accesses and kernel oopses. The upstream remedy adds a teardown flag and a state_lock to the usb_gadget structure and changes the scheduling path so work is only queued while the gadget is not being torn down — a surgical change that eliminates the observable UAF while remaining straightforward to backport and test.

Background​

USB gadget stack and the UDC core​

The Linux USB gadget framework lets a device behave as a USB peripheral. At the heart of gadget handling sits the UDC (USB Device Controller) core and per-device gadget structures that track endpoints, state, and a small internal workqueue used to defer sysfs notifications and other state-change processing. The kernel exposes members such as gadget->work, gadget->state_lock, and gadget->teardown in recent documentation and patches; these fields govern scheduling and synchronization for gadget state transitions.

How workqueues and teardown interact​

Workqueues are a common kernel mechanism to defer work outside interrupt or critical contexts. When gadget teardown begins — for example, when device_del or usb_del_gadget runs — the kernel must ensure no pending or future work items can access gadget memory after it is freed. Earlier attempts to fix races simply moved flush_work around device_del to ensure queued work had completed, but this approach left a residual race: a new work item could be scheduled after flush_work returns and just before the gadget's memory is released. The result: a work item runs while the gadget structure is freed, producing a UAF. This precise failure mode is what CVE-2025-68282 addresses.

---

What the vulnerability is (technical summary)​

• Vulnerability ID: CVE-2025-68282
• Affected component: Linux kernel — usb: gadget: udc
• Vulnerability class: use-after-free (race condition during teardown)
• Trigger: usb_gadget_set_state may schedule gadget->work while usb_del_gadget is tearing down the gadget, and a new work item can slip between flush_work and gadget memory free.
• Observable symptom: KASAN invalid-access traces or kernel oops with stack traces referencing sysfs_notify and usb_gadget_state_work.

Why this was possible: the code path that schedules gadget work did not check whether a teardown was already in progress. Moving flush_work around device_del mitigated an earlier variant (CVE-2025-21838), but that change alone could not prevent a new worklet from being enqueued after the flush and before free — a classic time-of-check/time-of-use (TOCTOU) window in teardown sequences. The new fix adds an explicit teardown marker set before flushing and a state_lock to ensure the scheduling site refuses to queue work once teardown has started, fully closing the race window.

---

How the upstream patch fixes it​

The upstream approach is deliberately conservative and low risk:

• Add a boolean teardown field to struct usb_gadget and a state_lock spinlock to protect it.
• Set the teardown flag in usb_del_gadget before calling flush_work, so no further scheduling is permitted once teardown begins.
• Make usb_gadget_set_state acquire the state_lock, check teardown, and only queue gadget->work if teardown is not set.
• Keep flush_work semantics to drain any already-queued items; the teardown flag prevents newly scheduled work after that point.

This pattern — mark-teardown-then-flush-then-free — is a well-known safe teardown idiom in kernel driver design. It trades a tiny amount of additional wiring (a flag + lock) for a robustly closed race. The patch is intentionally narrow, targeted at the exact scheduling window that produced the KASAN trace, minimizing risk of unintended regressions. Discussion and reviews on kernel lists outlined the rationale and supplied small iterative patch revisions before the stable backports were prepared.

---

Practical impact and exploitability​

Primary impact: availability​

The most immediate and realistic outcome is denial-of-service / instability: kernel oopses, KASAN triggers (on debug kernels), or panics that require reboots. In production, especially for embedded appliances and virtual hosts that provide USB passthrough, a malicious or buggy USB device could provoke these failures. Public trackers that catalog the report emphasize availability as the primary impact.

Exploitability — what’s realistic today​

• Attack vector: local or local-adjacent — the attacker must present a USB device or influence gadget lifecycle events (e.g., in guest-to-host passthrough scenarios).
• Privileges required: low or none in many configurations where device attachment is possible without elevated privileges.
• RCE likelihood: theoretical but not demonstrated — turning a kernel UAF into code execution typically requires a sequence of allocator and platform-specific primitives, and there is no public proof-of-concept (PoC) showing reliable exploitation into privilege escalation for this CVE at disclosure. Multiple trackers characterize the risk as availability-first with only theoretical escalation potential.

Affected population​

Not every Linux installation is exposed. The vulnerability is limited to kernels that include the UDC gadget code that uses the affected workqueue path. Many server or minimal images omit USB gadget functions by default; by contrast, embedded SoCs, device images, and virtualization hosts with USB passthrough are the highest-risk groups. Long-tail appliances with vendor-forked kernels are especially at risk because they may lag in backports.

---

Detection and incident-hunting​

Key telemetry signals to monitor:

• Kernel logs (dmesg/journalctl -k) containing KASAN invalid-access traces that include strings like sysfs_notify or function names such as usb_gadget_state_work.
• Oops backtraces that show workqueue context ("Workqueue: events usb_gadget_state_work") followed by invalid-access messages.
• Unexplained reboots or crashes correlated with USB attach/detach events.
• KASAN/AddressSanitizer traces in development/test fleets or syzbot reports that reproduce the race.

Example search artifacts (short form):

• journalctl -k | grep -i "usb_gadget_state_work"
• dmesg | grep -E "KASAN|invalid-access|usb_gadget|sysfs_notify"

If you capture vmcore or kdump, preserve the trace and map the gadget pointer addresses to kernel symbols; these artifacts help vendors reproduce and triage regression tests. Centralized kernel logging and retention will make trend detection possible across multiple hosts.

---

Recommended mitigations and operational playbook​

• Apply updates
• Install vendor/distribution kernels that include the upstream fix and reboot hosts into the patched kernel. The upstream commits are available in stable trees and distributions are releasing packages mapped to those commits.
• Short-term compensations if patching is delayed
• If gadget functionality is not required: unload or blacklist the gadget/UDC modules (for example, modprobe -r udc or blacklisting the relevant gadget modules). This eliminates the affected code path but may disable legitimate device features.
• Disable USB passthrough in hypervisors unless strictly required, and enforce strict device allowlists for critical systems.
• Enforce udev rules or hardware port locks to prevent untrusted USB devices from being attached to sensitive hosts.
• Test and validate
• After patching, reproduce representative attach/detach sequences in a test ring and verify the absence of prior oops/KASAN signatures.
• For embedded appliances, request vendor backports and images; test vendor-supplied kernels before field redeployment.
• Alerting
• Set SIEM alerts for kernel oopses co-occurring with USB attach/detach events and for KASAN traces mentioning gadget workqueue functions.

---

Why the upstream fix is good engineering — and its limits​

Strengths​

• Surgical and auditable: the change introduces a small, defensive guard (teardown flag + lock) that directly addresses the race window without large refactors, making review and backporting straightforward.
• Low regression risk: limited surface area and conservative semantics reduce the chance of breaking existing behavior.
• Detectable and testable: the pattern is reproducible in KASAN-enabled kernels and fuzzers, enabling QA teams to validate the fix.

Residual risks and caveats​

• Vendor lag: embedded and OEM kernels may not receive timely backports; those devices may remain vulnerable longer than mainstream distro kernels. Operators must contact vendors to request patched images.
• Similar races elsewhere: the gadget stack is large and has multiple scheduling and teardown points; this fix closes a known window but cannot guarantee there are no other UAF windows in other gadget or device-specific glue code.
• Operational tradeoffs of mitigations: blacklisting modules or disabling passthrough can have real operational impacts; weigh these against exposure and business risk.

---

For kernel developers: why this class of fix matters​

This CVE exemplifies the class of lifetime-ordering and race issues that surface under concurrent device events and interrupt paths. The pragmatic lesson for maintainers is twofold:

• Where workqueues are used to defer sysfs or state notifications, clearly document and enforce a teardown protocol: set teardown → flush → free.
• Prefer explicit state locks or atomics around scheduling paths; do not rely solely on flush_work ordering as it cannot prevent new work items submitted between flush and free.

These mitigations are low-cost and high-value: small additions of state and locking eliminate systemic TOCTOU windows and reduce noisy KASAN findings in CI and in the field. The maintainers’ choice to land a narrow, well-documented fix is consistent with that engineering principle.

---

Policy and operational recommendations for organizations​

• Treat Linux kernel CVEs affecting device drivers as first-class patch items where the affected systems expose physical USB or permit passthrough. Inventory virtualization hosts, developer workstations, kiosks, and embedded appliances for gadget support.
• For cloud and appliance users: query vendor attestations, security advisories, or CSAF/VEX artifacts where available and map image SKUs to kernel fixes; do not assume an image is safe simply because it is not listed. Microsoft and other cloud vendors sometimes publish attestations for specific images, but those are product-scoped and not universal — verify per-image.
• Prioritize systems by exposure: high-touch endpoints with physical USB access and VMs with passthrough capabilities should be ahead in the patch queue.
• Maintain kernel logging and kdump/boot core collection for all critical hosts to enable post-incident forensic analysis.

---

Final assessment (critical analysis)​

CVE-2025-68282 is a textbook kernel robustness fix: high operational impact (availability), limited exploitability without additional primitives, and straightforward remediation. The fix’s design — marking teardown while guarding the scheduling site with a lock — addresses the root cause (a scheduling window) rather than applying brittle ordering workarounds. That makes the patch robust and suitable for backports to stable kernel series.
However, the real-world threat model still depends on context. Attackers need local access to present USB devices or compromise a device/firmware chain. The long tail of embedded devices and OEM kernels remains the greatest operational worry; those installations can remain vulnerable for months if vendors do not prioritize backports. For defenders, the mitigations are clear: patch promptly, restrict USB device attachment where possible, and centralize telemetry so attempted triggers produce observable signals.
In short: the kernel community implemented a clean, low-risk fix that ends a concrete class of UAF; the operational priority now rests with maintainers, vendors, and administrators to patch or enact compensating controls to close the exposure window across deployed fleets.

---

Appendix — Quick checklist for WindowsForum readers (practical)

• Inventory: identify devices/images that ship USB gadget/UDC support (grep kernel config or check loaded modules).
• Patch: apply your distro/vendor kernel update that includes the CVE-2025-68282 commit and reboot.
• Short-term: if gadget features aren’t required, blacklist the UDC/gadget modules or disable USB passthrough in hypervisors.
• Monitor: add SIEM rules for KASAN/usb_gadget_state_work oops traces and retain vmcore dumps for any suspicious crashes.

Concluding note: the fix is an example of disciplined kernel engineering — small, targeted, and reviewable — but operators must not rely on upstream alone; patch management, vendor engagement, and device-access controls are the operational levers that close the window of risk for real deployments.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center