CVE-2026-16148 in Zephyr
Summary
by MITRE • 09/14/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in the ITE it82xx2 USB device-controller driver stems from a critical race condition and improper resource management within the kernel's workqueue subsystem. Specifically, the driver initializes its bus-suspend detection work item using k_work_init_delayable inside the enable operation of the driver interface. This function unconditionally overwrites the entire k_work_delayable structure, including internal timeout nodes and queue linkage pointers, without performing any check to determine if the work item is currently active or pending in a kernel list. Under normal operational conditions, this work item is scheduled continuously while the USB bus remains active, with the interrupt handler rescheduling it on every Start of Frame (SOF) interval and the handler itself recursively scheduling subsequent timeouts. Consequently, the timeout node is persistently linked within the kernel's internal data structures for managing delayed works and timers.
The core technical flaw occurs during a standard disable-then-enable cycle performed by the USB device controller framework. When the driver is disabled via it82xx2_disable(), the pending work item is not explicitly cancelled or flushed from the queue. Instead, when the system subsequently calls udc_enable() to re-initialize the device, which in turn invokes the driver's enable operation, k_work_init_delayable is executed again on the same memory structure that still contains active linkage pointers to kernel lists. This action corrupts these linked lists by overwriting valid pointers with uninitialized or stale data structures. The corruption of internal kernel synchronization primitives leads directly to a kernel panic, effectively crashing the operating system instance hosting the USB controller driver.
From an operational impact perspective, this vulnerability represents an unauthenticated denial of service that is reachable across the physical USB boundary. An external USB host can trigger the necessary state transitions by performing actions such as issuing a DFU detach command using tools like dfu-util or by forcing repeated attach and reset sequences to force re-enumeration. These actions drive the udc_disable followed immediately by udc_enable sequence, allowing an attacker with physical access to arrange for the suspend work to remain pending across the re-enable event. While there is no demonstrated impact on confidentiality or integrity of data stored on the host system, the resulting kernel panic renders the device completely unusable until a reboot occurs, disrupting any services relying on that hardware connection.
This issue aligns with CWE-362, which describes concurrent execution race conditions involving shared resources without proper synchronization, and specifically relates to improper handling of dynamic memory or object lifecycle states where an object is re-initialized while still in use. In the context of the MITRE ATT&CK framework for enterprise environments, this vulnerability facilitates Denial of Service (T1499) by exploiting a local privilege escalation path that requires physical proximity but no prior authentication on the target system. The exploitation vector relies on manipulating hardware state transitions rather than software logic errors in application code, highlighting risks associated with embedded systems and peripheral drivers exposed to external interfaces.
The remediation strategy involves restructuring the driver initialization sequence to ensure idempotency of resource setup. By moving the k_work_init_delayable call into a one-time pre-initialization function that runs only once during device probe or early boot, the work item is guaranteed to be initialized exactly before it enters any active state. This eliminates the possibility of re-initializing an in-use item during subsequent enable cycles. Additionally, best practices for kernel driver development dictate that disable operations should explicitly cancel pending delayed works using functions like cancel_delayed_work_sync to ensure all scheduled tasks have completed and are removed from internal queues before the structure is potentially reused or freed. Implementing these changes ensures robust state management and prevents corruption of critical kernel data structures during normal device lifecycle transitions.