CVE-2026-10647: Zephyr USB CDC-NCM Deadlock on Bus Suspend

Technical summary

The CDC-NCM (USB Communications Device Class–Network Control Model) driver in Zephyr's subsys/usb/device_next/class/usbd_cdc_ncm.c fails to validate the return value of usbd_ep_enqueue() in the cdc_ncm_send() transmit callback. When the host suspends the USB bus, the enqueue fails with -EPERM; similarly, disconnect, reset, or endpoint disable return -EPERM or -ENODEV. The driver ignores this failure and proceeds to call k_sem_take(&data->sync_sem, K_FOREVER), blocking indefinitely on a semaphore that is only signaled by the bulk-IN transfer-completion interrupt handler. Because no transfer was enqueued, that handler never executes, leaving the calling thread (a shared network traffic-class TX worker) permanently blocked while holding the interface transmit lock. The TX path cannot proceed, and the transmit buffer is leaked. The guard condition at transmission time checks only DATA_IFACE_ENABLED and IFACE_UP flags, not the suspended state, so a packet sent while the bus is suspended will trigger the deadlock. The underlying cause is a missing error check combined with a race between the host's suspend state and device packet queuing.

Business impact

Any embedded device running Zephyr with USB networking becomes unable to send data after the USB host suspends the bus—a common occurrence when a host PC sleeps or enters power-saving mode. The virtual network interface becomes unresponsive, requiring a device reboot to restore connectivity. For edge devices, IoT appliances, or remote systems that rely on USB connectivity to a laptop or gateway, this creates unacceptable downtime. Secondary impact occurs on devices with multiple network interfaces sharing the same TX worker thread; stalling the CDC-NCM path can cascade to other egress traffic. The defect is a hard denial of service with no graceful recovery short of power cycling.

Affected systems

Zephyr RTOS versions through v4.4.0 are affected if they include USB CDC-NCM networking support. Any device firmware built with the vulnerable driver and configured to use USB-based networking is at risk. This includes the vast ecosystem of Zephyr-based embedded devices, including wireless modules, IoT platforms, and development boards that support network-over-USB connectivity. Scope is limited to Zephyr devices; host-side Windows, Linux, or macOS drivers are unaffected.

Exploitability

Exploitation requires no special privileges or credentials; it is triggered by normal USB host behavior. Any host that implements USB suspend (standard power management on nearly all PCs, laptops, phones, and hubs) will trigger the condition. The device does not need to be actively transmitting—merely having an active network interface and the arrival of a packet to transmit while the bus is suspended is sufficient. From an attacker's perspective, this is trivial to induce: a malicious or compromised host can deliberately suspend the bus, then cause the device to attempt transmission (e.g., by probing the network interface or inducing ARP requests). No user interaction is required on the device side. However, this is fundamentally a host-controlled trigger, making it difficult for a remote attacker to exploit unless they have local control of the USB connection.

Remediation

The fix requires checking the return value of usbd_ep_enqueue() in cdc_ncm_send(). Upon failure, the function must free the transmit buffer and return an error without calling k_sem_take(). This prevents the indefinite blocking. Vendors and integrators should apply the patch in the Zephyr repository (verify against the official Zephyr security advisory for exact version numbers and merge commits). For developers maintaining Zephyr-based products, update to a patched Zephyr release, or backport the fix if you are on a maintenance branch. No workaround exists without code changes.

Patch guidance

Update your Zephyr build to a release that includes the fix. The defect was introduced with the CDC-NCM driver and persisted through v4.4.0, so any release after the fix merge is safe. Consult the official Zephyr security advisory or release notes to identify the patched version for your branch. If you maintain a custom or long-term-support branch, backport the error-check fix from the main Zephyr repository. Rebuild your device firmware and reflash all affected units. Test by verifying that USB suspend no longer causes the TX path to hang (a host-side tool like usbmon on Linux or Wireshark on Windows can monitor bus state transitions).

Detection guidance

Monitor Zephyr device firmware versions in your fleet; any version at or below v4.4.0 that includes USB CDC-NCM support is vulnerable. Inspect build configurations or firmware manifests to identify CDC-NCM usage. On deployed devices, observe for reports of unexplained network loss after the host enters sleep or power-saving mode, especially if preceded by verbose error logs indicating USB bus events. Logs showing the TX thread stalled or a hang after a suspend event are diagnostic. USB descriptor inspection can confirm the presence of CDC-NCM in a device's USB configuration. No runtime detection or remote scanning signature exists; this is a code-review finding.

Why prioritize this

Although the CVSS score is 5.3 (MEDIUM), the practical impact is high for affected deployments. The condition is easily triggered by normal USB power management, the deadlock is permanent until reboot, and recovery is unavailable through software means. For IoT and embedded systems where USB is a primary connectivity path and manual intervention is difficult or impossible, this escalates to critical priority. Prioritize based on your environment: critical if you have remote or managed Zephyr devices; high if you have USB-networked Zephyr devices in managed local environments; medium if you control the USB hosts and can disable suspend. The defect is already fixed upstream, so patching is straightforward once you identify affected devices.

Risk score, explained

CVSS 5.3 reflects the narrow attack surface (local USB, host-initiated trigger) and lack of confidentiality or integrity impact. The -1 modifier for attack complexity (requires USB suspend, a host action) and accessibility (adjacent network, USB connection required) keeps the score in the MEDIUM band. However, the availability impact is high because it is a complete and irreversible denial of service on the network path. The score does not fully capture the operational severity for remote or autonomous devices where a reboot is impractical. Organizations with strong USB sleep policies or isolated devices may find this lower-risk; those relying on USB as a fallback or primary link should treat it as higher priority.

Frequently asked questions