Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.2",
  "pubDate": "2026-08-11T06:17:12.747Z",
  "pubdate": "2026-08-11T06:17:12.747Z",
  "executiveSummary": "A heap-based buffer overflow vulnerability exists in the USB device-side CDC NCM class control-to-host handler within the Zephyr RTOS device_next USB stack. The vulnerability is classified as a heap buffer overflow caused by an insufficient bounds check when copying fixed-size structures into control DATA IN buffers allocated based on the host-supplied wLength field.\nAn unauthenticated USB host or malicious USB interposer can exploit this flaw by issuing standard CDC NCM control requests—specifically GET_NTB_PARAMETERS or GET_NTB_INPUT_SIZE—with a maliciously small wLength value. Because assertion checks are compiled out in production builds, this triggers an out-of-bounds write of up to 27 bytes past the boundary of the allocated network buffer pool.\nThe primary impact of successful exploitation includes heap memory corruption and subsequent denial of service affecting the USB stack. While information disclosure is prevented because the operation performs no read-backs, the corruption of adjacent allocations and metadata within the shared udc_ep_pool can destabilize the device.\nMitigation requires clamping the copy operation to ensure it does not exceed the host-supplied length, aligning the implementation with safer handlers like the existing CDC ACM class handler.",
  "technicalDetails": "The vulnerability resides in the usbd_cdc_ncm_cth function located within subsys/usb/device_next/class/usbd_cdc_ncm.c. This function acts as the control-to-host handler for the USB device-side CDC NCM class. When processing GET_NTB_PARAMETERS or GET_NTB_INPUT_SIZE class requests, the handler builds fixed-size responses corresponding to the 28-byte struct ntb_parameters and the 8-byte struct ntb_input_size, respectively.\nThe root cause stems from the manner in which control DATA IN buffers are allocated and populated. The USB stack allocates the buffer using usbd_ep_ctrl_data_in_alloc, which calls udc_ctrl_data_alloc and subsequently net_buf_alloc_len(&udc_ep_pool, wLength). Crucially, the buffer capacity is allocated exactly to the size specified by the host-supplied wLength field from the USB SETUP packet, without applying any round-up logic for the IN endpoint.\nTo populate the buffer, the handler invokes net_buf_add_mem(buf, ..., sizeof(...)), which directly copies the entire underlying structure into the buffer. The underlying net_buf_simple_add helper relies solely on an __ASSERT_NO_MSG check to enforce boundaries. In production builds, assertions are typically compiled out, rendering this check ineffective.\nThe step-by-step attack flow involves an attacker connecting a device or utilizing a USB interposer against a Zephyr-based device running an image compiled with the device_next USB stack and the CDC NCM class enabled. The attacker issues a standard CDC NCM control request (GET_NTB_PARAMETERS or GET_NTB_INPUT_SIZE) where the wLength field in the USB SETUP packet is set to a value significantly smaller than the corresponding response structure size, such as wLength = 1.\nUpon receiving the request, the vulnerable usbd_cdc_ncm_cth handler attempts to copy the full structure into the undersized buffer. Because the bounds check is absent in production builds, the memcpy routine writes up to 27 bytes past the end of the allocated udc_ep_pool buffer. This out-of-bounds write corrupts adjacent memory allocations and internal metadata within the shared udc_ep_pool.\nPost-exploitation impact is constrained by the fixed size of the overflow (<= 27 bytes) and the fact that the written payload consists entirely of fixed device constants rather than attacker-controlled data. The bug performs no reads, eliminating information disclosure risks, but reliably induces memory corruption and crashes or paralyzes the USB stack, resulting in a denial of service."
}