CVE-2026-10656: Zephyr MAX32 USB Driver NULL Pointer Crash – Denial of Service

Technical summary

CVE-2026-10656 is a NULL pointer dereference in udc_max32.c, the MAX32xxx USB device controller driver in Zephyr. The vulnerability exists in the transfer-completion handlers udc_event_xfer_out_done() and udc_event_xfer_in_done(), which call net_buf_add() on a buffer pointer returned by udc_buf_get() without validating it. udc_buf_get() returns NULL when the endpoint FIFO is empty. Because transfer-completion events are queued from interrupt context and processed asynchronously, the FIFO can be drained between event queuing and processing—particularly when udc_setup_received() drains EP0 FIFOs on new SETUP packets, or when dequeue/disable/purge paths run. A USB host aborting an in-flight EP0 control transfer with a new SETUP packet (legal per USB specification) causes a stale XFER_OUT_DONE event to be processed against an empty FIFO, invoking net_buf_add(NULL, ...) and faulting the device. The fix adds NULL-buffer checks that return UDC_EVT_ERROR/-ENOBUFS before dereferencing. The root cause is CWE-476 (NULL pointer dereference).

Business impact

For organizations deploying Zephyr-based USB devices (embedded systems, IoT peripherals, medical devices, industrial controllers), this vulnerability enables a denial-of-service attack via simple USB protocol manipulation. An attacker with physical access to the USB port can crash the device by aborting control transfers—no credentials, authentication, or software exploitation is required. Systems expected to operate continuously (industrial sensors, remote monitoring devices, medical implants) face unplanned downtime and loss of functionality. The attack is trivial to reproduce and requires only a standard USB host and knowledge of basic USB protocol. For supply-chain and managed-service scenarios, a malicious USB port or compromised development environment could expose many devices.

Affected systems

Zephyr v4.4.0 and later versions ship the MAX32 UDC driver. The affected driver is drivers/usb/udc/udc_max32.c, compatible with ADI MAX32xxx microcontrollers (adi_max32_usbhs). Any embedded system, IoT device, or peripheral built on Zephyr using the MAX32 USB device controller is vulnerable until patched. This includes prototypes and production systems deployed since Zephyr v4.4.0 (released mid-2024). Systems on earlier Zephyr versions are not affected because the driver did not exist. The scope depends on how widely MAX32 microcontrollers are used in deployed products; organizations should audit their hardware bills of materials and Zephyr versions.

Exploitability

Exploitability is high in practice. The attack requires only physical USB access—no network connectivity, software vulnerability chaining, or privilege escalation. The USB protocol manipulation (aborting a control transfer with a new SETUP packet) is well-defined and routine in USB operation; legitimate USB hosts do this during error recovery or protocol negotiation. An attacker simply connects to the USB port and sends a new SETUP packet to interrupt an in-flight control transfer, triggering the device crash. No specialized tools beyond a standard USB host controller are needed. Attack surface is the USB port itself; if a device's USB port is physically accessible or can be reached via USB hubs in untrusted environments, it is exploitable. The CVSS score of 4.6 (MEDIUM) reflects attack vector (Physical) and impact (Availability only); the practical difficulty of triggering the crash is low.

Remediation

Apply the security patch when released by the Zephyr project. The fix adds NULL-buffer checks in udc_event_xfer_out_done() and udc_event_xfer_in_done() to validate the buffer pointer before calling net_buf_add(). If the buffer is NULL, the handlers return UDC_EVT_ERROR/-ENOBUFS and avoid dereferencing. Immediately after patching, rebuild and deploy firmware to all affected devices. For devices that cannot be easily updated in the field (embedded, remote, or isolated), evaluate risk based on USB access controls: if the USB port is physically restricted, protected by access controls, or in a controlled environment, the risk may be accepted pending update windows. Document Zephyr version and MAX32 UDC driver status in your device inventory to track which systems require priority patching.

Patch guidance

Monitor the Zephyr project's official security advisories and release notes for the patch. The fix should be included in a maintenance release of the affected Zephyr version branch. Verify the patch by reviewing the udc_max32.c code changes in the release notes or git history to confirm NULL-checks are added to both transfer-completion handlers. Rebuild firmware with the patched Zephyr source, verify that USB device behavior under control-transfer interruption remains functional (no spurious errors), and deploy to production devices following your device firmware update procedures. If Zephyr provides a backport for v4.4.0 and earlier versions of the v4.x branch, apply it to minimize disruption to systems on stable release trains. Test on representative hardware (MAX32xxx evaluation boards) before rolling out to production.

Detection guidance

Empirical detection requires monitoring device logs and behavior: watch for unexpected device reboots or loss of USB connectivity following USB control-transfer attempts, particularly in test or development environments where USB activity is higher. On the Zephyr device side, enable UDC driver debug logging if available (via Kconfig CONFIG_USB_UDC_LOG_LEVEL) to capture UDC_EVT_ERROR events or NULL-buffer conditions. In security monitoring, flag any devices running Zephyr v4.4.0+ with MAX32 hardware that have not yet received the patch. Proof-of-concept can be generated by connecting a Python libusb or pyusb host to initiate an EP0 control transfer and interrupt it with a new SETUP packet; device crash is unambiguous evidence of vulnerability. No silent exploitation is possible; the attack reliably crashes the device, so intrusion detection focuses on device availability anomalies rather than subtle behavioral changes.

Why prioritize this

Prioritize patching for devices in high-availability or safety-critical roles (industrial controllers, medical devices, remote monitoring systems) and for devices with exposed or untrusted USB ports. Deprioritize for devices in secure physical environments with controlled USB access (lab prototypes, isolated test benches). The CVSS score (4.6 MEDIUM) underweights the practical simplicity of triggering the crash; treat this as a high-availability risk rather than a confidentiality/integrity breach. Devices requiring continuous operation should be patched as soon as a firmware update is available. Document MAX32-based inventory and Zephyr versions to avoid surprises in future patch cycles.

Risk score, explained

CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H yields 4.6 MEDIUM. Attack Vector (P) reflects physical USB access. Attack Complexity (L) captures the ease of invoking the crash via routine USB protocol. Privileges Required (N) and User Interaction (N) recognize that any USB host can exploit this without special setup. Scope (U) and Confidentiality/Integrity (N) indicate no system-boundary escape or data compromise. Availability (H) reflects total device crash. The score is driven by high availability impact but constrained by physical-access requirement. In environments where USB ports are shared or untrusted, actual risk exceeds the CVSS score.

Frequently asked questions