CVE-2026-16659: Pre-authentication NULL pointer dereference in MCUboot serial-recovery image upload (encrypted-image builds)

MCUboot's serial-recovery image-upload handler bsupload() in boot/bootserial/src/bootserial.c declares const struct flasharea fap = NULL and assigns it only via flashareaopen() part-way through the function. Two early validation failures (goto outinvaliddata) — 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 MCUBOOTENCIMAGES builds that epilogue unconditionally calls boothandleencfw(fap), which reaches bootimageloadheader() and flasharearead() and dereferences the NULL flasharea.

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 — imgnum, curroff and imgsize are zero-initialized statics, so curroff == imgsize and the primary-slot test both hold. It requires a non-default build: encrypted images (MCUBOOTENCIMAGES / Zephyr CONFIGBOOTENCRYPTIMAGE) together with an active serial-recovery transport, on the Zephyr or Mynewt port (the two that build both boot/bootserial/src/bootserial.c and bootserialencryption.c with MCUBOOTENCIMAGES).

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 flashareaclose(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 bootserial.c under CONFIGMCUBOOTSERIAL and bootserialencryption.c under CONFIGBOOTENCRYPTIMAGE — and the Mynewt port, whose mcubootconfig.h defines MCUBOOTSERIAL unconditionally and MCUBOOTENCIMAGES under any BOOTUTILENCRYPT syscfg, with boot/bootserial/pkg.yml declaring no explicit source list so the whole directory is built. The Espressif port is not affected: it compiles bootserial.c but not bootserialencryption.c, and defines no MCUBOOTENCIMAGES, so the #ifdef MCUBOOTENCIMAGES block containing the call is preprocessed away. The NuttX, Cypress and Mbed ports do not build bootserial.c at all.