The USB CDC-NCM device class (subsys/usb/device_next/class/usbd_cdc_ncm.c) ignores the return value of usbd_ep_enqueue() in its ethernet transmit callback cdc_ncm_send(). When the enqueue fails, the function still calls k_sem_take(&data->sync_sem, K_FOREVER), blocking on a completion semaphore that is only ever signaled from the bulk-IN transfer-completion callback. Because nothing was enqueued, that callback never fires and the calling thread — a shared network traffic-class TX thread — deadlocks permanently while holding the interface TX lock, halting transmission until reboot (and leaking the transmit buffer).

The enqueue fails under conditions controlled by the attached USB host: usbd_ep_enqueue() returns -EPERM whenever the bus is suspended (a standard, persistent host operation), and the underlying udc_ep_enqueue() returns -EPERM/-ENODEV on disconnect, bus reset, or endpoint disable. The cdc_ncm_send() guard only checks the DATA_IFACE_ENABLED and IFACE_UP flags, not the suspended state, so a packet transmitted while the host holds the bus suspended reaches the failing enqueue and deadlocks the TX path.

The realistic trigger is a bus suspend that occurs while the exported network interface is active and has traffic to send — host sleep, USB selective/auto-suspend, or hub power management — after which any device-originated packet deadlocks the path, recoverable only by reboot. The impact is a persistent loss of the virtual network connection between the host's NCM interface and the Zephyr device; because the deadlocked thread is a shared traffic-class TX thread, egress on other network interfaces can stall as well. There is no memory corruption or information disclosure.

The defect was introduced with the CDC-NCM driver and shipped in releases through v4.4.0; it is fixed by checking the usbd_ep_enqueue() return value and freeing the buffer before the blocking wait.

Affected components

• subsys/usb/device_next/class/usbd_cdc_ncm.c

Affected versions

All releases with the USB device_next CDC-NCM class through v4.4.0 (~v4.1.0..v4.4.0)

Fix

Fixed (merged) in 255bccc

Projected fixed version: 4.5.0 (the fix is merged on main but not yet released; this forecast should be confirmed against the actual release).

Introduced by: 8169ca2 "usb: device_next: NCM driver for usb-next" (Oct 2024); NCM driver present since ~v4.1.0

Evidence

• subsys/usb/device_next/class/usbd_cdc_ncm.c:1089-1097 — pre-fix the enqueue return was ignored and k_sem_take(K_FOREVER) followed unconditionally; the fix returns on failure after net_buf_unref
• subsys/usb/device_next/class/usbd_cdc_ncm.c:656-658 — sync_sem is only given from the bulk-IN completion callback, so a failed enqueue means it is never signaled
• subsys/usb/device_next/class/usbd_cdc_ncm.c:1040-1046 — send guard checks DATA_IFACE_ENABLED + IFACE_UP only, NOT CDC_NCM_CLASS_SUSPENDED, so a packet passes the guard while suspended
• subsys/usb/device_next/class/usbd_cdc_ncm.c:874-880 — suspend handler sets SUSPENDED bit but leaves DATA_IFACE_ENABLED set
• subsys/usb/device_next/usbd_endpoint.c:139-153 — usbd_ep_enqueue returns -EPERM for IN endpoints when usbd_is_suspended() is true
• drivers/usb/udc/udc_common.c:551-576 — udc_ep_enqueue returns -EPERM/-ENODEV when controller/endpoint disabled (disconnect/reset)
• subsys/usb/device_next/usbd_core.c:176-181 — UDC_EVT_SUSPEND from the host sets usbd_status_suspended(true); host-controlled bus state
• subsys/net/ip/net_if.c:293-295 — net_if_tx holds the per-iface TX lock across net_if_l2()->send(), so the deadlock holds the iface TX lock; the failed packet's egress path also keeps the calling thread parked
• subsys/net/ip/net_tc.c:285-367 — TX runs on a small fixed pool of traffic-class threads (tx_q[i]) shared across all interfaces, so a thread permanently blocked in cdc_ncm_send stalls egress for every interface using that class, not just NCM
• git show v4.4.0:subsys/usb/device_next/class/usbd_cdc_ncm.c:1088-1089 — vulnerable unchecked enqueue + k_sem_take(K_FOREVER) shipped in v4.4.0 (reportable)

Patches

For more information

If you have any questions or comments about this advisory:

• Open an issue in zephyr
• Email us at Zephyr-vulnerabilities

embargo: 2026-06-23