CVE-2026-31756

What it actually does

This is a Linux kernel denial-of-service flaw in the Synopsys DesignWare USB 2.0 controller gadget driver, commonly referenced as dwc2 gadget mode. A kernel function stops the USB gadget controller and calls a helper that expects an internal spinlock to already be held. Because the caller does not hold that lock, the helper can attempt to unlock an unlocked spinlock and then leave lock state inconsistent, which can lead to undefined kernel behavior or a deadlock later in the same stop path. The practical technical impact is local availability loss: a user or process with sufficient local ability to trigger USB gadget stop/reconfiguration paths may be able to hang the affected kernel or affected USB gadget subsystem. There is no indication from the provided data of confidentiality or integrity impact, remote exploitation, or code execution.

Why it matters to the business

Affected systems that use the Linux dwc2 USB gadget driver may become unstable or hang when the vulnerable gadget stop path is triggered, potentially causing service interruption, device unavailability, or required manual recovery. The greatest risk is to embedded Linux devices, appliances, development boards, OT/IoT devices, phones, and USB peripheral-mode systems that expose or rely on dwc2 gadget functionality. The vulnerability is not listed in CISA KEV, has very low EPSS, no known exploit maturity, and has not been flagged as ransomware-used, so broad active exploitation is unlikely based on current intelligence; however, the operational impact can still be significant for devices where local users, containers, management scripts, or physical access can manipulate USB gadget state.

How an attack unfolds

An attacker first needs local access to an affected Linux system and enough permission to interact with USB gadget functionality, such as through gadget configuration interfaces, privileged service controls, device management tooling, or another local path that causes the dwc2 gadget driver to stop the USB device controller. The attacker repeatedly or deliberately triggers the gadget stop path. In vulnerable kernels, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without first acquiring the expected hsotg->lock. The helper invokes a callback path that assumes the lock is held and performs spin_unlock/spin_lock around the callback. Because the lock state is incorrect, the kernel may unlock a lock that was not held and later deadlock when the same function attempts to acquire the lock again. The end result is a local denial of service, typically seen as a kernel hang, soft lockup, hard lockup, watchdog reset, or USB gadget subsystem failure.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for the dwc2 gadget locking mismatch in dwc2_hsotg_udc_stop(). No exact fixed package versions were provided in the input, so use the fixed kernel version published by the operating system, appliance, board-support-package, or embedded Linux vendor. Prioritize devices that use the dwc2 USB controller in gadget/peripheral mode. Where immediate patching is not possible, reduce exposure by disabling unused USB gadget functionality, unloading or blacklisting the dwc2 gadget driver if operationally safe, restricting access to configfs/sysfs gadget controls, limiting local shell access, preventing untrusted containers or services from manipulating USB gadget state, and using watchdog/recovery controls for embedded devices. Because this is kernel code, application-level mitigations are not sufficient if the vulnerable driver remains reachable.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch by checking the installed kernel package changelog, vendor advisory, or source tree for the corrected dwc2_hsotg_udc_stop() behavior where hsotg->lock is acquired before calling dwc2_gadget_exit_clock_gating() and released afterward. Verify whether the affected driver is present or loaded by checking kernel configuration and loaded modules for dwc2 gadget support. On Linux systems, review outputs such as uname -a, package manager kernel version details, modinfo where applicable, lsmod, /proc/modules, /boot/config-$(uname -r), and /sys/kernel/config/usb_gadget presence. Validate mitigation by confirming unused gadget functions are disabled, access to gadget configuration paths is restricted, and normal USB gadget stop/start operations no longer produce lockdep, spinlock, soft lockup, or watchdog messages in kernel logs. Avoid destructive proof-of-concept testing on production systems because triggering the bug can intentionally hang the kernel.

Typical attack path

1. Gain local access to an affected Linux system where the dwc2 USB controller is present and operating in gadget/peripheral mode.
2. Obtain or abuse permissions that allow USB gadget configuration, teardown, driver unbind, service restart, or other actions that invoke the gadget controller stop path.
3. Trigger a stop or reconfiguration event for the dwc2 gadget controller.
4. Cause the vulnerable locking sequence in dwc2_hsotg_udc_stop() to call dwc2_gadget_exit_clock_gating() without holding the expected spinlock.
5. Induce lock-state corruption or a deadlock in kernel context.
6. Result in local denial of service, such as a hung kernel, watchdog reset, unavailable USB gadget function, or system requiring reboot.

How to detect it

Look for evidence of kernel instability around USB gadget stop, reconfiguration, driver unbind, service restart, or device disconnect events. Primary log sources are kernel ring buffer logs, persistent system logs, crash dumps, pstore/ramoops records on embedded devices, watchdog reset logs, and distribution-specific journal logs. On systemd-based systems, review journalctl -k and previous-boot journals for dwc2, gadget, spinlock, lockdep, hung task, soft lockup, hard lockup, and watchdog messages. On embedded systems, also review serial console captures, bootloader reset reasons, /sys/fs/pstore contents, and vendor health telemetry. Suspicious signs include dwc2_hsotg_udc_stop or dwc2_gadget_exit_clock_gating in stack traces, spin_unlock warnings, lockdep splats, kernel oopses, or repeated device resets following USB gadget configuration changes. Because exploitation requires local access and no public exploit maturity is indicated, focus correlation on local administrative commands, configfs/sysfs writes, service restarts, container privilege changes, physical access events, and time proximity to kernel lockup or reboot artifacts.

• dwc2_hsotg_udc_stop
• dwc2_gadget_exit_clock_gating
• call_gadget
• dwc2
• usb: dwc2
• gadget: Fix spin_lock/unlock mismatch
• BUG: spinlock
• spin_unlock
• spin_lock_irqsave
• lockdep
• possible circular locking dependency detected
• inconsistent lock state
• BUG: soft lockup
• BUG: hard lockup
• watchdog: BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP
• INFO: task hung
• blocked for more than 120 seconds
• kernel: hung_task
• /sys/kernel/config/usb_gadget
• /sys/class/udc
• /sys/bus/platform/drivers/dwc2
• /sys/module/dwc2
• /sys/fs/pstore
• ramoops
• pstore:

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and board-support-package images that use dwc2 USB gadget/peripheral mode.
• Prioritize remediation for devices where local users, containers, management agents, or physical operators can trigger USB gadget reconfiguration or shutdown.
• Apply the vendor-provided fixed kernel or firmware update that contains the dwc2_hsotg_udc_stop() locking fix.
• If patching is delayed, disable unused USB gadget functionality or restrict access to gadget control paths such as configfs and sysfs to trusted administrators only.
• Monitor kernel logs for spinlock, lockdep, hung task, soft lockup, hard lockup, watchdog reset, and dwc2-related messages that may indicate attempted triggering or instability.
• For embedded or remote devices, ensure watchdog and safe reboot mechanisms are configured so a local denial-of-service condition does not require manual recovery.
• Track vendor advisories because downstream fixed versions may differ by distribution, appliance firmware, and long-term-support kernel branch.
• Treat this as lower internet-scale urgency because it is local, not KEV-listed, has very low EPSS, and has no known exploit maturity, but still remediate in normal kernel maintenance cycles for affected gadget-mode systems.