CVE-2026-16664 in mcuboot
Summary
by MITRE • 11/13/2026
MCUboot's Zephyr serial-recovery upload handler bs_upload() in boot/boot_serial/src/boot_serial.c decodes the host-supplied image field of an MCUmgr image-upload request into img_num (a full 32-bit value) and latches it on the off == 0 packet without any range check. It then passes img_num straight to flash_area_id_from_multi_image_slot(img_num, 0), which on the Zephyr port resolves to __flash_area_ids_for_slot() in boot/zephyr/include/sysflash/sysflash.h and indexes the static const int all_slots[] table as all_slots[img_num 2]. That table holds only MCUBOOT_IMAGE_NUMBER 2 entries, so any img_num >= MCUBOOT_IMAGE_NUMBER is an out-of-bounds read.
The path is reachable by anyone with access to the serial / SMP recovery console, which is unauthenticated by design, and the bad value is supplied before any image signature is verified. The defect is specific to the default non-direct upload path (MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD disabled) on the Zephyr port with the array-backed slot layout (not CONFIG_SINGLE_APPLICATION_SLOT). It is not gated on a multi-image configuration: MCUBOOT_IMAGE_NUMBER defaults to 1, so even a default single-image build is affected for any image >= 1. The MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD path is safe (its flash_area_id_from_direct_image() switch returns -EINVAL for unknown indices).
flash_area_id_from_multi_image_slot() takes a signed int image_index while img_num is uint32_t, so the attacker controls the sign of the index as well as its magnitude: an image of 0xFFFFFFFF converts to -1 and reads all_slots[-2], off the front of the table, while large positive values read off the end (CWE-192). Either way the index multiply img * 2 is performed in int, so a wild offset yields a bus/hard fault, giving a reliable denial of service of the bootloader during recovery. For moderately out-of-range indices the read returns adjacent .rodata as a garbage flash-area id that is handed to flash_area_open(); this normally fails with MGMT_ERR_EINVAL, but if the garbage id happens to match a valid non-image partition, the subsequent erase/write can target a partition outside the image set (CWE-787). The attacker-supplied value is never echoed back, so there is no information disclosure. The fix is to reject img_num >= BOOT_IMAGE_NUMBER on the off == 0 packet, before the slot lookup. The comparison must be made on the unsigned img_num: an equivalent guard applied after the conversion to int would not reject the negative case above. __flash_area_ids_for_slot() should bounds-check its own arguments as defence in depth.
This vulnerability was reported independently twice: by NVIDIA Project Vanessa on 2026-06-22, and by Kai Phan (@kaimandalic) on 2026-07-19 as GHSA-8v33-88p6-jffj, which is closed as a duplicate of this advisory. Both original reports are reproduced in full below.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified in MCUboot's Zephyr serial-recovery upload handler constitutes a critical out-of-bounds read and potential memory corruption flaw within the boot_serial module. Specifically, the bs_upload function processes image-upload requests received via the unauthenticated Serial Management Protocol (SMP) console used for firmware recovery. When handling an off == 0 packet, which signifies the start of an image upload sequence, the handler decodes the host-supplied image field into a full thirty-two-bit unsigned integer variable named img_num without performing any initial range validation. This value is then passed directly to the flash_area_id_from_multi_image_slot function, which on the Zephyr port resolves to __flash_area_ids_for_slot in sysflash.h. This internal routine calculates an index by multiplying img_num by two and uses it to access a static constant array named all_slots. The size of this array is determined by MCUBOOT_IMAGE_NUMBER multiplied by two, meaning that any image number greater than or equal to MCUBOOT_IMAGE_NUMBER results in accessing memory outside the bounds of the allocated table. This behavior aligns with CWE-192, which classifies integer conversion errors leading to out-of-bounds reads, and represents a significant deviation from secure coding practices regarding input validation prior to array indexing operations.
The operational impact of this flaw is severe due to the specific execution context in which it occurs. The serial recovery console is designed to be unauthenticated by design to allow for device recovery when standard boot methods fail or are compromised. Consequently, any physical attacker with access to the UART interface can exploit this vulnerability before any image signature verification takes place. Because img_num is a thirty-two-bit unsigned integer but flash_area_id_from_multi_image_slot expects a signed integer index, an attacker has full control over both the magnitude and the sign of the resulting array offset. Supplying a value such as 0xFFFFFFFF causes the conversion to result in -1, leading to an out-of-bounds read at all_slots[-2], which accesses memory preceding the start of the table. Conversely, large positive values cause reads beyond the end of the array. In either scenario, the multiplication operation img_num * two is performed using signed integer arithmetic, meaning that wild offsets frequently result in invalid pointer calculations or bus errors. This reliably triggers a hard fault or exception within the bootloader, resulting in a denial of service during the critical recovery phase. The system may reboot indefinitely or become unresponsive, effectively bricking the device if it cannot recover from this state through external means.
Beyond immediate denial of service, there is a secondary risk associated with moderately out-of-range indices that do not immediately cause hardware faults. In these cases, the read operation returns adjacent data located in the .rodata section as a garbage flash-area identifier. This invalid identifier is subsequently passed to flash_area_open for further processing. While this typically fails and returns an error code such as MGMT_ERR_EINVAL, there exists a scenario where the garbage value coincidentally matches a valid non-image partition identifier within the system's memory map. If this occurs, subsequent erase or write operations could target partitions outside the intended image set, potentially corrupting critical configuration data, bootloader metadata, or other persistent storage areas. This aligns with CWE-787, which describes out-of-bounds writes that can lead to arbitrary code execution or system instability, although in this specific instance, the primary vector is an uncontrolled read leading to erroneous state transitions rather than direct memory overwrite via buffer overflow. The attacker-supplied value is not echoed back to the client, thereby mitigating information disclosure risks associated with CWE-200, but the integrity of the boot process remains severely compromised.
The vulnerability is specific to the default non-direct upload path in MCUboot on Zephyr systems where MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD is disabled and the array-backed slot layout is utilized rather than CONFIG_SINGLE_APPLICATION_SLOT. It affects even single-image configurations because MCUBOOT_IMAGE_NUMBER defaults to one, meaning any image number greater than or equal to one triggers the out-of-bounds condition. The direct upload path remains safe as it employs a switch statement in flash_area_id_from_direct_image that explicitly returns -EINVAL for unknown indices, demonstrating that proper input validation is feasible within this codebase. To mitigate this issue, developers must implement strict bounds checking on img_num immediately upon receipt of the off == 0 packet and before any slot lookup occurs. The comparison must be performed against the unsigned thirty-two-bit value to ensure that negative values resulting from sign conversion are also rejected; applying a guard after converting to signed integer would fail to catch cases like 0xFFFFFFFF which become -1. Additionally, implementing defense in depth by adding bounds checks within __flash_area_ids_for_slot itself is recommended to prevent similar issues if other callers introduce vulnerabilities. This flaw maps to ATT&CK techniques related to initial access via physical interface and potential impact on system availability through resource exhaustion or denial of service conditions during firmware update processes.