CVE-2026-16662: Uninitialised bootloader stack disclosed into the measured-boot attestation record via a short EXPECTED_HASH TLV in MCUboot

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

The defect is reachable only under MCUBOOTMEASUREDBOOT, and only when the image reaching bootsavebootstatus() was not hash-validated on that boot. bootutilimgvalidate() rejects a hash TLV whose length is not exactly sizeof(hash) (boot/bootutil/src/imagevalidate.c:345), and primary-slot validation is on by default (Zephyr's CONFIGBOOTVALIDATESLOT0 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 MCUBOOTVALIDATEPRIMARYSLOT, which checks only the image magic before calling bootaddshareddata(), and the Zephyr single-slot loader (boot/zephyr/singleloader.c) built without it, including the MCUBOOTVALIDATEPRIMARYSLOTONCE 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 EXPECTEDHASHTLV, 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 (IMAGEHASHSIZE - 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 bootsavebootstatus(). It is reported as a low-severity, defense-in-depth disclosure with no integrity or availability impact.

This is distinct from the already-fixed recordlen integer underflow in the same routine (GHSA-8hrv-4cp5-4rg3). The fix rejects any EXPECTEDHASHTLV whose length is not exactly IMAGEHASHSIZE.