CVE-2026-127915: TLV iterator does not bound each entry against the declared TLV area in MCUboot bootutil
The MCUboot TLV iterator bootutiltlviternext() in boot/bootutil/src/tlv.c walks image trailer TLVs with a single loop guard (it->tlvoff < it->tlvend) and advances by sizeof(struct imagetlv) + tlv.itlen using the attacker-controlled itlen field, without validating that the entry's header or payload stays within it->tlvend. As a result the 4-byte header read can extend up to 3 bytes past the declared TLV area, and the returned (off, len) can describe a payload that runs past it.
The path is pre-authentication: TLVs are parsed during bootutilimgvalidate() before the signature is verified, and a crafted image can be presented through DFU / serial-recovery / OTA. However the impact is contained by surrounding guards: bootutilimgvalidate() first rejects a TLV area larger than bootutilmaximagesize(), the default LOADIMAGEDATA sink is flasharearead() which bounds-checks against the flash partition and fails an out-of-partition read, and every payload consumer (EXPECTEDHASHTLV, EXPECTEDKEYTLV, EXPECTEDSIGTLV, IMAGETLVSECCNT) clamps len against a fixed buffer before copying.
The residual effect in a default flash build is therefore an out-of-region read confined to the attacker's own slot partition whose result is never observable, yielding at worst a clean validation failure rather than memory corruption or information disclosure. A genuine (though still bounded) out-of-bounds read remains under the non-default MCUBOOTRAMLOAD configuration, where LOADIMAGEDATA is an unchecked memcpy. The fix is to validate each entry's header and payload against it->tlvend inside the iterator.
Event History
Frequently Asked Questions
What access does an attacker need to reach the vulnerable parsing path?
An attacker must be able to present a crafted image to the device through an image-delivery path such as DFU, serial recovery, or OTA. The TLVs are parsed before signature verification, so a valid signature is not required to reach this code.
What limits the impact in a default flash-backed build?
The default LOAD_IMAGE_DATA implementation, flash_area_read(), rejects reads outside the flash partition. In addition, the listed TLV payload consumers clamp lengths to fixed buffer sizes before copying, limiting the residual effect to an out-of-region read confined by surrounding checks.
Are non-default image-loading implementations covered by the stated protections?
The described containment specifically relies on the default flash_area_read() sink and its partition bounds checks. The provided information does not assess custom LOAD_IMAGE_DATA implementations, so their read-boundary behavior should be reviewed separately.