CVE-2026-31754

What it actually does

This is a local denial-of-service flaw in the Linux kernel Cadence USB3 dual-role device controller driver. If cdns3_gadget_start() fails during gadget initialization, the hardware can remain in gadget mode while the kernel software state remains INACTIVE. A later switch from gadget mode to host mode through the USB role-switch interface may skip required cleanup, violating the controller’s expected idle-before-role-change sequence. When the xHCI host controller is then initialized, the inconsistent hardware/software state can trigger a synchronous external abort and kernel crash. The primary impact is loss of availability; no confidentiality or integrity impact is indicated by the published details.

Why it matters to the business

Systems using affected Linux kernels with Cadence USB3 dual-role controller hardware may be vulnerable to local crashes during USB role switching. On embedded, mobile, industrial, appliance, or development-board platforms that rely on USB gadget/host mode transitions, exploitation or accidental triggering can cause service interruption, device reboot, loss of active sessions, and operational downtime. The issue is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so urgency is highest for systems where local users or exposed management workflows can influence USB role switching.

How an attack unfolds

An attacker first needs local access with sufficient permission to interact with USB gadget configuration or the USB role-switch sysfs interface. They cause or wait for a failure in gadget initialization, leaving the Cadence DRD controller hardware in gadget mode while the kernel believes the role is inactive. The attacker then requests a switch to host mode, commonly through the sysfs USB role-switch interface. Because the software state is still INACTIVE, the driver skips the cleanup path that should return the controller to idle before changing roles. When the host-side xHCI controller setup runs, it accesses the controller in an invalid state and the kernel raises a synchronous external abort, resulting in a system crash or reboot.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the cdns3 gadget error path. The fix ensures cdns_drd_gadget_off() is called when cdns3_gadget_start() fails, returning the DRD controller to a safe state before later role changes. No exact fixed package versions were provided in the input, so track the fix through the Linux kernel stable trees and the relevant distribution or vendor kernel advisories for the deployed platform. As interim mitigation, restrict write access to USB role-switch sysfs nodes and USB gadget configuration interfaces to trusted administrators only, disable unnecessary USB gadget/dual-role functionality where feasible, and avoid exposing local shell or management access on devices where USB role switching is not required.

How to confirm the fix worked

Confirm the running kernel includes the patch that adds proper cdns_drd_gadget_off() cleanup on the cdns3_gadget_start() failure path. Validate through vendor package metadata, kernel changelogs, source inspection, or distribution security advisories. On affected hardware, verify that USB role switching from a failed gadget initialization state no longer produces kernel oops, panic, synchronous external abort, or xHCI setup failure messages. Also confirm that unprivileged users cannot write to /sys/class/usb_role/*/role or manipulate USB gadget configuration unless explicitly required.

Typical attack path

1. Gain local access to a Linux system using the Cadence cdns3 USB dual-role controller driver.
2. Obtain permission to configure USB gadget mode or write to the USB role-switch sysfs interface.
3. Trigger a gadget initialization failure so the hardware remains in gadget mode while the driver state remains INACTIVE.
4. Switch the USB role from gadget/device mode to host mode.
5. Cause xHCI host controller initialization to run against the inconsistent DRD controller state.
6. Crash the kernel, causing a denial of service.

How to detect it

Review kernel logs, persistent journal data, console logs, crash dumps, pstore/ramoops, and device management logs for evidence of gadget initialization failures followed by USB role switching and xHCI host setup crashes. Useful sources include journalctl -k output, /var/log/kern.log, /var/log/messages, dmesg captures, pstore records under /sys/fs/pstore, kdump/vmcore data, and embedded-device serial console logs. Look for the sequence of cdns-usb3 or configfs-gadget start failures, role-switch errors, xHCI Host Controller initialization, and a synchronous external abort or kernel oops with stack frames such as xhci_gen_setup, usb_add_hcd, and cdns_role_set. Because exploitation requires local interaction, correlate any crash timing with shell history, sudo logs, auditd records, management-agent activity, or configuration changes involving /sys/class/usb_role/*/role and USB gadget/configfs paths. There are no public threat actors or ransomware campaigns reported for this issue in the provided data.

• configfs-gadget 13180000.usb: failed to start g1: -19
• cdns-usb3 13180000.usb: Failed to add gadget
• cdns-usb3 13180000.usb: set role 2 has failed
• Internal error: synchronous external abort: 96000010
• xhci_gen_setup+0xa4/0x408
• xhci_plat_setup+0x44/0x58
• usb_add_hcd+0x284/0x678
• cdns_role_set+0x9c/0xbc
• xHCI Host Controller
• /sys/class/usb_role/
• /sys/class/usb_role/*/role
• cdns3_gadget_start
• cdns_drd_gadget_off
• cdns-usb3
• configfs-gadget

What your security team should do

• Inventory Linux systems and embedded devices that use Cadence cdns3 USB dual-role controller hardware or load cdns3/cdns-usb3 related drivers.
• Prioritize remediation for devices where local users, containers, field technicians, management scripts, or exposed services can influence USB gadget configuration or USB role switching.
• Apply the vendor-supported kernel update containing the cdns3 gadget initialization failure cleanup fix as soon as it is available for the affected platform.
• Until patched, restrict access to USB role-switch and USB gadget configuration interfaces using file permissions, service hardening, device policy, and least-privilege administrative controls.
• Monitor kernel logs for cdns-usb3 gadget start failures followed by USB role changes, xHCI setup, synchronous external aborts, kernel oops, or unexpected reboots.
• For appliances and embedded products, coordinate with the device vendor for firmware updates because the vulnerable code may be delivered as part of a board-support package rather than a general-purpose distribution kernel.