CVE-2026-16662

boot save boot status() in boot/bootutil/src/boot record.c reads the image's EXPECTED HASH TLV into a stack buffer image hash[IMAGE HASH SIZE] that is never zero-initialised. The TLV handler validates only the upper bound (len > sizeof(image hash)) and then reads exactly len bytes, so a TLV shorter than IMAGE HASH SIZE leaves the tail of image hash holding stale stack content. The subsequent copy into the boot record, memcpy(buf + offset, image hash, sizeof(image hash)), uses the fixed buffer size rather than len, so up to IMAGE HASH SIZE - 1 bytes of uninitialised bootloader stack are written into the measured-boot record.

The defect is reachable only under MCUBOOT MEASURED BOOT, and only when the image reaching boot save boot status() was not hash-validated on that boot. bootutil img validate() rejects a hash TLV whose length is not exactly sizeof(hash) (boot/bootutil/src/image validate.c:345), and primary-slot validation is on by default (Zephyr's CONFIG BOOT VALIDATE SLOT0 defaults to y), so in a default build the malformed image never reaches this code. The direct-XIP and RAM-load strategies in boot/bootutil/src/loader.c validate the selected slot unconditionally and are not affected. The short TLV survives only where the integrator has turned primary-slot validation off: the swap and overwrite loader built without MCUBOOT VALIDATE PRIMARY SLOT, which checks only the image magic before calling boot add shared data(), and the Zephyr single-slot loader (boot/zephyr/single loader.c) built without it, including the MCUBOOT VALIDATE PRIMARY SLOT ONCE variant, which skips validation once the trailer records an earlier successful one. It is also reachable through a time-of-check/time-of-use change to tamperable external flash between validation and the boot-record read. Placing the crafted image requires physical or flash-write access to the device; in a single-slot build with serial recovery enabled, the serial-recovery upload writes the primary slot directly and can place it as well.

In these configurations the boot record's measurement is already not trustworthy: with validation off, the hash copied into the record is the image's own unverified EXPECTED HASH TLV, which the attacker chooses. The defect therefore does not weaken attestation integrity any further. What it adds is a path for bootloader memory to leave the device: up to 63 bytes (IMAGE HASH SIZE - 1) of uninitialised bootloader stack are embedded in the measurement field that a downstream attestation service sends to a remote verifier. In the configurations analysed the residue is bootloader internal state (TLV offsets and lengths, flash addresses, loop state), not key material, but what occupies that stack region depends on configuration and on which code ran before boot save boot status(). It is reported as a low-severity, defense-in-depth disclosure with no integrity or availability impact.

This is distinct from the already-fixed record len integer underflow in the same routine (GHSA-8hrv-4cp5-4rg3). The fix rejects any EXPECTED HASH TLV whose length is not exactly IMAGE HASH SIZE.