PT-2026-146111
CVE-2026-16659
·
Published
2026-11-13
·
Updated
2026-11-13
Description by
CVSS 3.1
4.0
MediumMetricsAV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
MCUboot's serial-recovery image-upload handler bs upload() in boot/boot serial/src/boot serial.c declares const struct flash area *fap = NULL and assigns it only via flash area open() part-way through the function. Two early validation failures (goto out invalid data) — a CBOR map that fails to decode, or an upload packet missing the off/data members — branch past the open while fap is still NULL, then fall into the shared epilogue. In MCUBOOT ENC IMAGES builds that epilogue unconditionally calls boot handle enc fw(fap), which reaches boot image load header() and flash area read() and dereferences the NULL flash area.
The defect is reachable pre-authentication: the trigger is the very first serial-recovery upload command carrying a malformed payload. The guarding conditions are default-true on a fresh recovery session — img num, curr off and img size are zero-initialized statics, so curr off == img size and the primary-slot test both hold. It requires a non-default build: encrypted images (MCUBOOT ENC IMAGES / Zephyr CONFIG BOOT ENCRYPT IMAGE) together with an active serial-recovery transport, on the Zephyr or Mynewt port (the two that build both boot/boot serial/src/boot serial.c and boot serial encryption.c with MCUBOOT ENC IMAGES).
The impact is a transient denial of service of the bootloader during recovery. fap is a hard NULL rather than an attacker-controlled value, so there is no memory-corruption or information-leak primitive and image authentication is unaffected. Whether the dereference faults is platform-dependent — on targets where address 0x0 is mapped readable flash the read merely returns an error and execution continues, while targets that trap NULL (MPU / null-pointer-exception detection) take a hard fault. Because serial recovery is unauthenticated by design and already permits the console attacker to write the secondary slot, the added capability is only a low-value transient crash.
The related unconditional flash area close(fap) call in the same epilogue is a safe no-op on the ports that reach it, so it does not contribute to the dereference.
The affected ports are the Zephyr port — boot/zephyr/CMakeLists.txt compiles boot serial.c under CONFIG MCUBOOT SERIAL and boot serial encryption.c under CONFIG BOOT ENCRYPT IMAGE — and the Mynewt port, whose mcuboot config.h defines MCUBOOT SERIAL unconditionally and MCUBOOT ENC IMAGES under any BOOTUTIL ENCRYPT syscfg, with boot/boot serial/pkg.yml declaring no explicit source list so the whole directory is built. The Espressif port is not affected**: it compiles boot serial.c but not boot serial encryption.c, and defines no MCUBOOT ENC IMAGES, so the #ifdef MCUBOOT ENC IMAGES block containing the call is preprocessed away. The NuttX, Cypress and Mbed ports do not build boot serial.c at all.
Found an issue in the description? Have something to add? Feel free to write us 👾