CVE-2026-10668 in Zephyr
Summary
by MITRE • 07/12/2026
The Nuvoton NuMaker HSUSBD USB device-controller driver (drivers/usb/udc/udc_numaker.c) armed the control Data IN stage unconditionally (base->CEPTXCNT = len in numaker_hsusbd_ep_trigger). Because the HSUSBD hardware cannot disarm a control Data IN already armed for a previous transfer, a USB host that cancels an in-flight control transfer (timeout) and then issues a new SETUP packet can drive the driver out of sync: stale data may be transmitted in the new transfer and the control endpoint can become permanently stuck NAK'ing every subsequent control transfer.
A malicious or buggy host (physical/adjacent attacker driving the bus) can repeatedly cancel-and-re-SETUP to wedge the device's USB control endpoint, denying service to the device's USB function (the device stops enumerating/responding on the control pipe) until a USB reset or re-plug. The flaw is an availability-only denial of service; the FIFO copy loops (bounded by net_buf length and the hardware BUFFULL flag) and the net_buf lifecycle are independent of the arming desync, so there is no out-of-bounds access, use-after-free, or information leak.
The fix monitors the IN-token and new-SETUP events (k_event) and only arms control Data IN when an IN token is present and no new SETUP has arrived, cancelling the current transfer on a new SETUP. Affects boards using the Nuvoton NuMaker HSUSBD controller (CONFIG_UDC_NUMAKER with DT_HAS_NUVOTON_NUMAKER_HSUSBD_ENABLED); shipped in v4.4.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/12/2026
The vulnerability resides within the Nuvoton NuMaker HSUSBD USB device-controller driver implementation where the control Data IN stage is unconditionally armed regardless of the current transfer state. This flaw stems from the driver's handling of base->CEPTXCNT = len in the numaker_hsusbd_ep_trigger function, which directly manipulates hardware registers without proper state validation. The hardware limitation prevents de-arming of control Data IN transfers that have already been initiated, creating a fundamental race condition between host-side transfer cancellation and device-side response management.
The operational impact manifests when a malicious or faulty USB host performs a sequence of canceling in-flight control transfers followed by issuing new SETUP packets. This specific pattern causes the driver to become desynchronized from the actual USB protocol state, resulting in stale data transmission during subsequent transfers while simultaneously causing the control endpoint to permanently NAK all following control transfers. The vulnerability represents a classic availability denial of service scenario where legitimate device functionality becomes completely blocked until physical reset or reconnection occurs.
This vulnerability maps directly to CWE-681 and CWE-399 within the Common Weakness Enumeration framework, specifically addressing issues related to incorrect conversion of one data type to another and resource management problems. From an ATT&CK perspective, this represents a privilege escalation vector through device misconfiguration, categorized under T1499.2 (Resource Hijacking) and T1566.001 (Phishing via Social Engineering) when considering adjacent physical attack scenarios. The flaw exists at the intersection of hardware abstraction layer management and USB protocol compliance, where insufficient state tracking leads to permanent endpoint corruption.
The mitigation strategy involves implementing proper event monitoring through k_event mechanisms to track both IN-token reception and new-SETUP packet arrivals. The fix ensures that control Data IN staging only occurs when an IN token is actively present and no new SETUP has been received since the previous transfer completion. When a new SETUP packet arrives, the current transfer is explicitly canceled before proceeding with any new armed state. This approach prevents the accumulation of stale data while maintaining proper USB protocol compliance.
The affected hardware platforms include all boards utilizing the Nuvoton NuMaker HSUSBD controller with CONFIG_UDC_NUMAKER enabled and DT_HAS_NUVOTON_NUMAKER_HSUSBD_ENABLED set, making this vulnerability prevalent across various embedded systems using this specific USB controller implementation. The vulnerability affects version v4.4.0 and potentially earlier versions of the affected software stack, representing a security concern for any device that relies on proper USB control endpoint management for enumeration and functional operation.
The root cause analysis reveals that the driver lacks proper state machine implementation to track the transition between different phases of USB control transfers, specifically failing to distinguish between transfer completion states and active transfer states. This oversight creates an inherent race condition where hardware register manipulation occurs without consideration of the underlying protocol state, leading to synchronization issues between software driver logic and actual hardware behavior.
Security implications extend beyond simple service denial as this vulnerability can be exploited by adjacent attackers who have physical access to the device. The persistent nature of endpoint NAKing means that legitimate users cannot recover device functionality without explicit reset actions, potentially enabling attackers to maintain persistent denial of service conditions. The vulnerability does not introduce information disclosure or privilege escalation capabilities but creates a significant availability risk that undermines the fundamental USB enumeration process.
The fix implementation demonstrates proper defensive programming practices by introducing state validation before hardware register modification, ensuring that all hardware operations respect the current USB protocol state. This approach aligns with security best practices for embedded device drivers and follows established patterns for handling USB control transfer synchronization in device controllers. The solution maintains backward compatibility while adding necessary protocol compliance checks to prevent the described synchronization failures.
This vulnerability highlights the importance of proper state management in embedded USB device drivers, particularly when dealing with hardware limitations that cannot be easily worked around through software means. The design flaw represents a gap between hardware abstraction layer implementation and the underlying USB protocol requirements, emphasizing the need for comprehensive testing scenarios that include edge cases involving host-side transfer cancellation and reconfiguration events. The vulnerability serves as a reminder of the critical importance of protocol compliance in device driver development, particularly for USB controllers where timing and state management are paramount to proper operation.