Description

The ITE it82xx2 USB device-controller driver initialized its bus-suspend detection work with k_work_init_delayable(&priv->suspended_work, suspended_handler) inside it82xx2_enable() (the driver's .enable op) in drivers/usb/udc/udc_it82xx2.c. This work item is scheduled essentially continuously while the USB bus is active: the interrupt handler reschedules it on every SOF frame and suspended_handler() reschedules itself, so its timeout node is normally linked in the kernel timeout list / a workqueue pending queue. k_work_init_delayable() (kernel/work.c) unconditionally overwrites the entire k_work_delayable structure, including its timeout and queue linkage, with no busy check. Because it82xx2_disable() does not cancel the work, a normal disable-then-enable cycle re-runs api->enable() (udc_enable() only rejects a redundant enable, not a re-enable after disable) and re-initializes the still-pending work in place, corrupting the kernel timeout/workqueue linked lists and causing a kernel panic. An external USB host — for example a host performing USB DFU detach (dfu-util --detach) or forcing repeated attach/reset/re-enumeration — drives the udc_disable()/udc_enable() transitions and controls suspend/resume timing, so it can arrange for the suspend work to be pending across a re-enable. This yields an unauthenticated denial of service (kernel panic) reachable across the USB boundary from a removable, physically-connected host, with no confidentiality or integrity impact demonstrated. The fix moves the k_work_init_delayable() call into the one-time preinit function so the work is initialized exactly once, eliminating the re-initialization of an in-use item.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.6",
  "pubDate": "2026-09-14T20:16:39.360Z",
  "pubdate": "2026-09-14T20:16:39.360Z",
  "executiveSummary": "The ITE it82xx2 USB device-controller driver is susceptible to a kernel panic caused by improper work-queue management during device state transitions.\nThe vulnerability type is a race condition leading to data structure corruption, specifically within the kernel's timeout and workqueue management mechanisms.\nThe flaw exists in the it82xx2_enable() function, where the k_work_delayable structure is unconditionally re-initialized while the work item may still be pending.\nAn unauthenticated attacker with physical access to the USB port can trigger this condition by issuing specific USB control requests—such as DFU detach or rapid device resets—to force the driver through an enable-disable-enable cycle.\nSuccessful exploitation results in a kernel panic, leading to a Denial of Service (DoS) of the affected embedded system.\nNo authentication or elevated privileges are required, as the vector is directly exposed via the USB physical interface.",
  "technicalDetails": "The root cause of the vulnerability is the misuse of k_work_init_delayable() within the it82xx2_enable() function located in drivers/usb/udc/udc_it82xx2.c. In the Zephyr kernel, k_work_init_delayable() performs an unconditional overwrite of the structure containing the timeout node and workqueue linkage. In the context of the it82xx2 driver, the suspended_work item is designed to be continuously scheduled, as it is re-queued by the interrupt handler on every SOF frame and by the suspended_handler() itself upon execution.\nThe it82xx2_disable() function fails to cancel the pending work item before the device state is transitioned. Consequently, when the driver is re-enabled, the it82xx2_enable() function executes again. Because the state machine allows re-enablement, the driver invokes k_work_init_delayable() on a structure that is still actively linked within the kernel's timer or workqueue lists. This operation corrupts the linked list pointers by overwriting them in place, causing the scheduler or timer subsystem to attempt traversal of a corrupted structure.\nThe attack flow relies on an external USB host, which controls the timing of USB bus events. An attacker can use operations like 'dfu-util --detach' or rapid USB bus resets to force the UDC to toggle between enabled and disabled states. By timing these requests to occur while the suspended_work item is pending, the attacker ensures that the kernel is mid-processing of the work item when it82xx2_enable() is triggered. This induces an inconsistent state in the kernel's timeout management logic.\nThe exploitation does not require prior authentication or elevated privileges, as the driver is exposed directly through the USB controller. The impact is a total system crash (kernel panic) due to the kernel's inability to safely traverse the corrupted workqueue or timer lists. While this vulnerability does not demonstrate confidentiality or integrity compromises, it effectively facilitates a persistent denial-of-service condition that requires a hard reboot to resolve."
}