CVE-2026-64454

What it actually does

This is a Linux kernel flaw in the DesignWare USB3 (dwc3) gadget driver suspend path. During gadget suspend, the kernel holds the dwc3 spinlock with interrupts disabled and invokes the gadget driver's disconnect callback from that non-sleepable context. If the callback performs an operation that may sleep, the kernel can trigger Lockdep warnings such as "BUG: sleeping function called from invalid context" and, depending on kernel configuration and runtime behavior, may destabilize the USB gadget subsystem or contribute to a local denial-of-service condition. The issue is tied to systems using USB gadget mode with dwc3-based controllers rather than general-purpose USB host use.

Why it matters to the business

Affected Linux-based devices that expose USB gadget functionality can experience instability, service interruption, or kernel diagnostic failures during USB suspend or disconnect handling. This is most relevant to embedded devices, appliances, Android/Linux-based hardware, development boards, and products that use USB gadget mode for networking, storage, serial, charging, or device-management functions. Public exploitation likelihood appears low at this time: EPSS is very low, there is no known CISA KEV listing, no ransomware association, and no mature public exploit is indicated.

How an attack unfolds

An attacker would need a way to influence USB gadget suspend or disconnect behavior on a vulnerable Linux system that uses the dwc3 gadget driver. In a plausible scenario, the attacker connects to or interacts with the device over USB, causes suspend/resume or disconnect transitions, and triggers the dwc3_gadget_suspend() path. The vulnerable path calls the gadget disconnect callback while interrupts are disabled and a spinlock context is active. If the selected gadget driver's disconnect callback performs sleepable work, the kernel detects an invalid sleeping context and may emit Lockdep errors, destabilize the gadget function, or create a denial-of-service condition. This is not a typical remote network exploit and generally requires local, physical, or device-adjacent ability to affect USB gadget state.

How to fix it

Apply the vendor kernel update that includes the upstream fix for the dwc3 gadget suspend disconnect handling. The fix runs the gadget disconnect callback from a sleepable suspend-side context after releasing the dwc3 lock with IRQ state restored. Because no product-specific fixed versions were provided, remediation should be tracked through the Linux distribution, device vendor, board support package, Android/common kernel branch, or embedded firmware provider that supplies the kernel. Where immediate patching is not possible, reduce exposure by disabling unused USB gadget functions, disabling gadget mode on affected devices, limiting physical access to USB ports, avoiding untrusted USB hosts, and validating whether the device actually uses the dwc3 gadget driver.

How to confirm the fix worked

Confirm that the running kernel or firmware contains the vendor fix for the dwc3 gadget suspend path. Validate exposure by checking whether the device has dwc3 gadget support enabled and active, for example through kernel configuration, loaded modules, device tree entries, dmesg output, or sysfs entries related to dwc3 and USB gadget functions. After patching, reproduce normal USB gadget suspend/resume and disconnect workflows under diagnostic logging and verify that kernel logs no longer show Lockdep reports or "sleeping function called from invalid context" messages from dwc3_gadget_suspend(), dwc3_disconnect_gadget(), or gadget_driver disconnect callbacks.

Typical attack path

1. Identify a Linux-based target that uses a dwc3 USB controller in gadget/device mode.
2. Gain physical, local, or device-adjacent ability to influence USB gadget connection state.
3. Trigger USB suspend, resume, or disconnect events against the gadget interface.
4. Cause execution of dwc3_gadget_suspend() followed by dwc3_disconnect_gadget() and the gadget driver's disconnect callback.
5. Induce a callback path that attempts to sleep while interrupts are disabled or a spinlock context is active.
6. Result in kernel Lockdep warnings, USB gadget malfunction, or possible denial of service depending on configuration and workload.

How to detect it

Review kernel logs, persistent system journals, crash dumps, pstore/ramoops records, and device telemetry for evidence of the vulnerable path being triggered. Look for Lockdep or kernel BUG reports mentioning sleeping in invalid context, dwc3_gadget_suspend(), dwc3_disconnect_gadget(), gadget_disconnect, or gadget_driver disconnect callbacks. Correlate events with USB suspend, resume, disconnect, cable attach/detach, USB-C role changes, OTG events, or interactions from attached USB hosts. Because this issue is a denial-of-service style kernel-context bug rather than malware behavior, there may be no attacker-specific network IOC. Repeated crashes or warnings immediately following USB gadget state changes may indicate attempted triggering or operational exposure.

• BUG: sleeping function called from invalid context
• gadget_disconnect+0x21/0x39
• dwc3_gadget_suspend.constprop.0+0x2b/0x42
• dwc3_gadget_suspend
• dwc3_disconnect_gadget
• gadget_driver->disconnect
• Lockdep reported
• usb: dwc3
• dwc3 gadget suspend
• sleeping function called from invalid context

What your security team should do

• Prioritize patching for embedded, mobile, appliance, industrial, or hardware products that expose USB gadget/device mode and use dwc3 controllers.
• Inventory Linux kernels and firmware images for dwc3 gadget driver usage, especially in products with USB-C, OTG, serial gadget, Ethernet gadget, mass-storage gadget, or device-management USB features.
• If patching is delayed, disable unnecessary USB gadget functions and restrict physical access to exposed USB ports.
• Monitor kernel logs for Lockdep, BUG, WARNING, suspend, and USB gadget disconnect anomalies on affected device classes.
• Coordinate with device vendors, BSP maintainers, Linux distribution maintainers, or Android kernel providers to obtain fixed builds because fixed package versions were not supplied in the input.
• Treat this as lower urgency than internet-facing remote code execution vulnerabilities, but address it in normal kernel and firmware maintenance cycles for products where USB gadget availability is operationally important.