Zephyr RTOS CVE-2026-12051

Exploitation requires all four of the following concrete conditions: (1) the target device must run Zephyr's experimental device_next USB stack, not the legacy USB stack; (2) the DFU class must be compiled in and enabled with a registered firmware image (the image->write_cb callback must be set); (3) the attacker must first advance the device to DFU_DNLOAD_IDLE state by successfully sending at least one valid DFU_DNLOAD data block followed by a GET_STATUS - this means a partial, valid firmware download initiation is required before the crash can be triggered; (4) the attacker must physically control the USB host attached to the device. Exploitation is strictly limited to availability impact (device crash/reset); the NULL+offset read does not provide a code execution primitive and the CVE description explicitly confirms no memory corruption or information disclosure path exists.

The CVSS 4.6 score with AV:P (Physical) accurately reflects the constrained attack surface: exploitation requires direct control of a USB host physically connected to the target device, limiting realistic attacker populations to insider threats, supply chain scenarios, malicious charging stations, or deliberate physical attack. The attack complexity is low once physical access exists, but the prerequisite of advancing the device to DFU_DNLOAD_IDLE state (a valid prior download block plus GET_STATUS) adds a non-trivial sequencing step. Impact is bounded to a device crash or reset - the CVE description and commit diff both explicitly rule out memory corruption and code execution. EPSS data was not provided in the input, and the vulnerability is not listed in CISA KEV. No public exploit code is known. The vulnerability is also scoped to the experimental device_next USB stack, narrowing the at-risk population further. The 'Buffer Overflow' and 'Information Disclosure' tags in the input metadata directly conflict with the CVE description and should be treated as erroneous metadata tagging artifacts. Real-world priority is low except in threat models where physical USB access by adversaries is a concern.

An attacker with control of a USB host connected to a vulnerable Zephyr device sends one valid DFU_DNLOAD data block followed by a GET_STATUS request to advance the device to DFU_DNLOAD_IDLE state, then sends a zero-length DFU_DNLOAD terminator. The handle_download() function dereferences the NULL buf pointer, triggering a fatal CPU fault that crashes or resets the device. No public exploit code is known; the attack steps are fully derivable from the DFU protocol specification and the CVE description.