CVE-2026-12051 in Zephyr
Summary
by MITRE • 08/11/2026
The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup->wLength, buf->len) and passes buf->data to the image write callback without checking that the buf net_buf pointer is non-NULL.
The handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it.
The result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability exists within the USB Device Firmware Update class implementation in Zephyr's experimental device_next USB device stack, specifically in the handle_download() function located at subsys/usb/device_next/class/usbd_dfu.c. This flaw represents a classic null pointer dereference condition that fundamentally undermines system availability. The issue manifests when processing USB control endpoint requests through the DFU_DNLOAD (download) command sequence, where the USB core invokes the class handler with a NULL buffer parameter during zero-length terminating download operations. These operations are integral to the DFU protocol's termination mechanism, requiring a final zero-length packet to conclude firmware transfers properly.
The technical execution path begins when a device transitions to the DFU_DNLOAD_IDLE state following successful transmission of one valid download block and subsequent GET_STATUS command processing. Under normal DFU protocol operation, this sequence concludes with a zero-length DFU_DNLOAD request that should be handled gracefully by the USB stack. However, the current implementation fails to validate whether the net_buf pointer received from the USB core is NULL before attempting to access its data member. The computation MIN(setup->wLength, buf->len) directly references buf->data without proper null checking, creating a direct path for a NULL+offset read that inevitably results in a fatal CPU fault.
This vulnerability operates within the broader context of USB device security and firmware update protocols, where malicious or compromised USB hosts can exploit this condition to induce device crashes or resets. The attack surface is limited to scenarios where an attacker controls the USB host device to which the vulnerable Zephyr system is connected, and where DFU download support has been enabled with a registered image. The impact classification aligns with CWE-476 Null Pointer Dereference, specifically manifesting as a denial of service condition that renders the device unavailable through forced reset or crash states. The ATT&CK framework categorizes this under privilege escalation and denial of service techniques where an attacker can manipulate system state to achieve availability disruption.
The operational implications extend beyond simple device restarts, as this vulnerability can be exploited to repeatedly crash systems in environments where continuous operation is critical. Since the USB interface is typically accessible to any connected host, the attack vector becomes particularly concerning for embedded systems deployed in automated or remote environments. The fix implementation requires adding a simple but crucial null pointer check with an explicit if (buf != NULL) guard that prevents the immediate dereference while allowing the callback to receive a properly formatted zero-length, NULL-data transfer. This approach maintains protocol compliance while preventing the crash condition and aligns with defensive programming practices recommended in secure software development guidelines. The solution demonstrates proper error handling for edge cases in USB communication protocols and prevents the propagation of invalid data structures through the device stack, thereby preserving system stability and availability.