The USB CDC-NCM device class (subsys/usb/devicenext/class/usbdcdcncm.c) ignores the return value of usbdepenqueue() in its ethernet transmit callback cdcncmsend(). When the enqueue fails, the function still calls ksemtake(&data->syncsem, KFOREVER), 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: usbdepenqueue() returns -EPERM whenever the bus is suspended (a standard, persistent host operation), and the underlying udcepenqueue() returns -EPERM/-ENODEV on disconnect, bus reset, or endpoint disable. The cdcncmsend() guard only checks the DATAIFACEENABLED and IFACEUP 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 usbdepenqueue() return value and freeing the buffer before the blocking wait.