EUVD-2026-55939Severity by source
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Physical USB host control required (AV:P); no auth needed on the device itself (PR:N); impact is crash-only with no confidentiality or integrity effect (C:N/I:N/A:H).
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
NULL pointer dereference in Zephyr RTOS's experimental device_next USB DFU class crashes any device where DFU download is enabled when a USB host sends a zero-length DFU_DNLOAD terminator after initiating a valid transfer. The result is a fatal CPU fault causing device crash or reset - impact is strictly limited to availability, with the vendor and commit diff explicitly confirming no memory corruption or information disclosure. No public exploit has been identified at time of analysis, and exploitation requires physical control of the attached USB host.
Technical ContextAI
The flaw is in subsys/usb/device_next/class/usbd_dfu.c within Zephyr's experimental device_next USB stack (distinct from the legacy USB stack). The DFU (Device Firmware Update) USB class protocol terminates a firmware download session with a zero-length DFU_DNLOAD request; the USB core correctly passes buf == NULL to the class handler in this case. The handle_download() function previously computed MIN(setup->wLength, buf->len) and passed buf->data to the image write callback without any NULL check on buf, resulting in a NULL+offset memory read. CWE-476 (NULL Pointer Dereference) precisely classifies the root cause. The upstream fix (commit 552ca371) inserts an explicit if (buf != NULL) guard so that a zero-length, NULL-data transfer is forwarded to the write callback instead of crashing. The CPE cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:* covers all Zephyr versions containing the device_next DFU implementation.
RemediationAI
Apply the upstream fix from commit 552ca371257597b71490482d5cc597157ea60f12, which adds a NULL-guard in handle_download() before accessing the buf net_buf pointer, resolving the crash on zero-length DFU_DNLOAD requests. Refer to the Zephyr GitHub Security Advisory GHSA-vhvq-q6rw-jvm4 at https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vhvq-q6rw-jvm4 for additional context and version guidance. Note that the patch is available from an upstream commit rather than a tagged release; a specific patched release version has not been independently confirmed from the available data. For devices where patching is not immediately feasible, disabling DFU download support entirely - by not registering an image with the DFU class - eliminates the vulnerable code path with no functional side effect for devices that do not require over-USB firmware updates. Restricting physical USB port access (port blocking, enclosures, or host allow-listing) provides an additional environmental layer but does not fix the underlying code defect.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
Buffer overflow in Zephyr RTOS dns_unpack_name() function causing OOB writes. PoC available.
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Same weakness CWE-476 – NULL Pointer Dereference
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today