CVE-2026-64347

What it actually does

This Linux kernel USB gadget flaw is an invalid empty-list handling bug in the composite gadget control request path. In the USB OTG descriptor handling branch of composite_setup(), the kernel uses list_first_entry() to obtain the first USB configuration even when the configuration list may be empty. Because list_first_entry() does not return NULL for an empty list, the subsequent NULL check is ineffective. If a USB control transfer for an OTG descriptor is processed while no gadget configuration exists, the kernel may treat the list head as a usb_configuration object and read an invalid descriptors[0] pointer. That data is then copied into the USB response buffer up to the requested length. The likely technical outcomes are kernel memory disclosure to the USB host, a kernel crash or KASAN fault, and denial of service. The vulnerable condition can occur during a teardown race while unbinding a gadget driver or in a gadget driver that enables OTG before adding a configuration.

Why it matters to the business

Systems that expose Linux USB gadget functionality can become unstable or leak kernel memory when interacting with a malicious or malfunctioning USB host. This primarily affects embedded devices, appliances, development boards, phones, USB peripherals, and systems using Linux USB gadget mode rather than ordinary USB client use. Operational consequences may include device crashes, service interruptions, difficult-to-diagnose USB failures during attach/detach events, and potential exposure of sensitive kernel memory. The EPSS score is currently low and the issue is not listed in CISA KEV, indicating no known broad exploitation at this time, but kernel fixes should still be prioritized for products that expose USB gadget mode to untrusted hosts or are physically accessible.

How an attack unfolds

An attacker needs access to interact with a vulnerable Linux system while it is operating as a USB gadget device, typically by controlling the USB host side or inducing control transfers during gadget setup or teardown. The attacker causes or waits for a state where the composite gadget has OTG enabled but the configuration list is empty, such as during a race with gadget unbind or through a gadget driver initialization path that sets OTG before adding configurations. The attacker then sends a USB control request that reaches the OTG descriptor branch in composite_setup(). Because the kernel incorrectly assumes a configuration object exists, it reads from memory derived from the list head rather than a valid usb_configuration. The response path may copy unintended kernel memory into the USB request buffer, or the invalid access may trigger a kernel fault and crash the device. Practical exploitation is likely timing- and configuration-dependent, and there is no public evidence in the supplied data of active exploitation or mature exploit code.

How to fix it

Apply the vendor or distribution kernel update that includes the upstream fix changing the empty-list handling to use list_first_entry_or_null() so the existing NULL check works correctly. Because no specific affected product list or fixed package versions were provided, remediation should be based on the Linux distribution, embedded BSP, Android/common kernel branch, appliance firmware, or kernel source tree used by the product. For source-based builds, verify that the USB gadget composite code in drivers/usb/gadget/composite.c contains the corrected empty-list-safe logic in the USB_DT_OTG handling path. If immediate patching is not possible, reduce exposure by disabling unnecessary USB gadget functions, disabling OTG gadget mode where not required, avoiding untrusted USB hosts, limiting physical access to gadget-capable devices, and reviewing custom gadget drivers to ensure configurations are added before OTG is enabled and that unbind paths quiesce control requests safely.

How to confirm the fix worked

Confirm remediation by checking that the running kernel or firmware build includes the upstream composite gadget fix for the USB_DT_OTG handler. For source validation, inspect drivers/usb/gadget/composite.c and verify that the OTG branch does not use list_first_entry() in a way that can return the list head for an empty cdev->configs list; the corrected logic should use list_first_entry_or_null() or equivalent empty-list-safe handling before dereferencing config->descriptors[0]. For binary or packaged systems, confirm the installed kernel package, firmware image, or vendor advisory references the fix. For exposure validation, determine whether CONFIG_USB_GADGET and relevant composite gadget drivers are enabled and whether the product can operate in USB gadget/OTG device mode. In test environments, attempt USB gadget bind/unbind and OTG descriptor control-transfer testing with kernel sanitizers or debug kernels enabled; the fixed build should not produce KASAN faults, invalid reads, or crashes in composite_setup().

Typical attack path

1. Identify a target device or product that runs Linux USB gadget/composite functionality and exposes OTG descriptor handling.
2. Gain the ability to act as or control the USB host connected to the gadget device, or otherwise influence USB control transfers during gadget lifecycle events.
3. Trigger or wait for a gadget state where cdev->configs is empty, such as during gadget driver unbind/teardown or before a configuration is added.
4. Send a crafted or timed USB control request for the OTG descriptor path handled by composite_setup().
5. Cause the kernel to evaluate an empty configuration list using list_first_entry(), resulting in an invalid usb_configuration pointer.
6. Receive unintended data copied into the USB response buffer or cause a kernel fault/denial of service.
7. Optionally repeat the timing sequence to collect additional leaked memory or repeatedly disrupt the device.

How to detect it

Look for evidence of kernel instability or sanitizer reports around Linux USB gadget composite handling. Primary log sources include kernel ring buffer output, persistent system logs, crash dumps, pstore/ramoops, kdump/vmcore artifacts, serial console logs, and device firmware diagnostic logs. Search for KASAN, UBSAN, general protection fault, NULL or invalid pointer dereference, slab out-of-bounds, page fault, or kernel oops messages with stack traces referencing composite_setup(), usb_composite_setup_continue(), composite_disconnect(), usb_gadget_unregister_driver(), gadget unbind paths, USB_DT_OTG handling, or drivers/usb/gadget/composite.c. Also correlate suspicious events with USB attach/detach, gadget bind/unbind, role-switch, OTG negotiation, and repeated control transfer activity from a connected host. Because exploitation may only produce a crash or memory disclosure over USB rather than durable files, absence of filesystem artifacts does not rule out attempted exploitation. There are no known threat actors, ransomware campaigns, or public exploitation indicators in the supplied data.

• composite_setup
• USB_DT_OTG
• drivers/usb/gadget/composite.c
• KASAN:
• BUG: KASAN:
• kernel BUG at drivers/usb/gadget/composite.c
• general protection fault
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• Internal error: Oops
• usb_gadget_unregister_driver
• composite_disconnect
• gadget unbind
• config->descriptors[0]

What your security team should do

• Inventory products, appliances, embedded systems, mobile devices, and development platforms that run Linux in USB gadget or OTG device mode.
• Prioritize patching systems where USB gadget functionality is exposed to physically accessible or untrusted USB hosts, even though current EPSS is low and the issue is not in CISA KEV.
• Request updated kernels, BSPs, or firmware from vendors if affected devices use vendor-maintained Linux kernels and no fixed version is published internally.
• For custom kernel or gadget-driver builds, backport the upstream composite.c fix and review driver initialization order so OTG is not enabled before at least one valid configuration exists.
• Temporarily disable USB gadget/OTG functions that are not operationally required, especially on devices deployed in uncontrolled physical locations.
• Monitor kernel logs for crashes, KASAN reports, invalid memory reads, or USB gadget errors involving composite_setup, USB_DT_OTG, or gadget unbind events.
• Treat unexpected device crashes or USB resets during host connection/disconnection as potentially relevant until patched and investigated.