CVE-2026-64347: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: composite: fix dead empty check in the USBDTOTG handler
The OTG branch of compositesetup() falls back to the first configuration when none is selected:
if (cdev->config) config = cdev->config; else config = listfirstentry(&cdev->configs, struct usbconfiguration, list); if (!config) goto done; ... memcpy(req->buf, config->descriptors[0], value);
listfirstentry() never returns NULL. On an empty list it returns containerof() of the list head. So the "if (!config)" check is dead.
When cdev->configs is empty, config points at the head inside struct usbcompositedev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to wlength bytes of it into the response buffer.
cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets isotg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch.
Use listfirstentryornull() so the existing check does its job.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler)to a version that resolves this vulnerability.Patch usb_composite_dev - Configuration
Apply the fix described: use list_first_entry_or_null() instead of list_first_entry() in the USB_DT_OTG handler so that when cdev->configs is empty the code does not mis-handle container_of(list head) and avoids KASAN faults.
USB gadget composite (USB_DT_OTG handler) if (!config) check = Remove/replace dead check; use list_first_entry_or_null() to handle empty cdev->configs safely
Event History
Frequently Asked Questions
Which systems are exposed to this condition?
Systems using the Linux USB gadget composite framework are exposed when the OTG request handler runs while the gadget has no configurations. The described empty-list state can occur during a gadget unbind teardown race or when a driver sets is_otg before adding a configuration.
What is required to trigger the fault?
The OTG branch must process a control transfer while cdev->configs is empty. In that state, the fallback uses list_first_entry(), producing a non-NULL invalid configuration pointer and causing descriptor data to be read and copied from an unintended location.
What is the expected impact?
The vulnerability is rated medium with CVSS 5.5 and affects availability only. A reproducer maintaining an empty configuration list triggers a KASAN fault in the affected branch.
What does the available fix change?
The fix replaces list_first_entry() with list_first_entry_or_null() in this path. This allows the existing null check to handle an empty configuration list instead of dereferencing the list head as a configuration object.