CVE-2026-12052 in Zephyr
Summary
by MITRE • 08/11/2026
The USB device-side CDC NCM class control-to-host handler usbd_cdc_ncm_cth in subsys/usb/device_next/class/usbd_cdc_ncm.c builds a fixed-size response for the GET_NTB_PARAMETERS (28-byte struct ntb_parameters) and GET_NTB_INPUT_SIZE (8-byte struct ntb_input_size) class requests and copies the whole structure into the control DATA IN buffer with net_buf_add_mem(buf, ..., sizeof(...)), ignoring the host-supplied wLength.
The control DATA IN buffer is allocated by the USB stack with a capacity of exactly wLength bytes (usbd_ep_ctrl_data_in_alloc -> udc_ctrl_data_alloc -> net_buf_alloc_len(&udc_ep_pool, wLength); no round-up is applied for the IN endpoint). Because net_buf_add_mem/net_buf_simple_add only bounds the copy with an __ASSERT_NO_MSG, which is compiled out in production builds, a host that issues one of these standard CDC NCM control requests with a wLength smaller than the response structure (e.g. wLength = 1) causes the handler to memcpy up to 27 bytes past the end of the allocated pool buffer.
The request fields come straight from the USB SETUP packet, so any host (or USB interposer) the Zephyr device enumerates against can trigger the overflow with no authentication once an image built with the device_next USB stack and the CDC NCM class is connected. The out-of-bounds write corrupts adjacent allocations and metadata in the shared udc_ep_pool, primarily causing memory corruption and denial of service of the USB stack; the overflow length is bounded (<= 27 bytes) and the written content is fixed device constants, and the bug reads nothing back so there is no information disclosure. The fix clamps the copy with MIN(sizeof(...), setup->wLength), matching the existing CDC ACM handler.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability described represents a critical buffer overflow condition in the USB device-side CDC NCM (Communication Device Class - Network Control Model) implementation within the Zephyr operating system's USB stack. This flaw exists in the control-to-host handler function usbd_cdc_ncm_cth located in subsys/usb/device_next/class/usbd_cdc_ncm.c, where the system fails to properly validate or constrain the response size against host-supplied parameters during standard class requests. The specific control requests affected are GET_NTB_PARAMETERS and GET_NTB_INPUT_SIZE, which are fundamental operations defined by the USB CDC NCM specification for negotiating network communication parameters between the device and host.
The technical implementation of this vulnerability stems from a fundamental mismatch between the fixed-size response structure and the dynamic allocation of the USB control buffer. When these control requests are processed, the system allocates a buffer with exactly wLength bytes of capacity as specified by the host in the USB SETUP packet, without any padding or rounding up. The handler then proceeds to copy either a 28-byte ntb_parameters structure or an 8-byte ntb_input_size structure into this buffer using net_buf_add_mem() operations that perform no bounds checking beyond compile-time assertions which are disabled in production builds. This creates a scenario where a malicious host can specify a wLength value smaller than the actual response structure size, leading to out-of-bounds memory writes that extend well beyond the allocated buffer boundaries.
The operational impact of this vulnerability is severe and affects all Zephyr-based devices implementing the device_next USB stack with CDC NCM class functionality. Since the request data originates directly from the USB SETUP packet, any host or USB interposer can trigger this condition without requiring authentication or special privileges once a device with this vulnerable code is connected to the system. The memory corruption primarily affects the shared udc_ep_pool memory pool used by the USB stack, causing adjacent memory allocations and metadata to become corrupted, which results in immediate denial of service conditions for the USB subsystem. This vulnerability operates at the kernel level within the USB device stack, making it particularly dangerous as it can potentially compromise the entire USB communication framework of the device.
This vulnerability maps directly to CWE-121 Stack-based Buffer Overflow and CWE-787 Out-of-bounds Write within the Common Weakness Enumeration framework, representing a classic case of improper bounds checking in kernel-level code. From an ATT&CK perspective, this represents a privilege escalation vector through a device driver vulnerability that could lead to persistent denial of service conditions, with potential for more severe consequences if combined with other memory corruption vulnerabilities in the same subsystem. The fix implemented addresses this by enforcing proper bounds checking using MIN(sizeof(...), setup->wLength) which aligns with existing patterns used in the CDC ACM handler implementation within the same codebase, ensuring that response data never exceeds the host-specified buffer limits while maintaining compatibility with the USB specification requirements for these control requests.
The limited nature of the overflow payload means that while this vulnerability causes significant memory corruption and denial of service conditions, it does not provide information disclosure capabilities since no data is read back from the corrupted memory regions. The maximum overflow size is bounded at 27 bytes, which represents the difference between the largest response structure (28 bytes) and typical small wLength values that could be specified by an attacker. This constraint limits the potential for more sophisticated exploitation techniques but does not eliminate the fundamental security risk posed by the memory corruption it causes, particularly when considering that such vulnerabilities often serve as stepping stones for more complex attack vectors in embedded systems environments.