{"id":"CVE-2026-16671","summary":"Out-of-bounds stack write in MCUboot split-image validation with SHA-384/SHA-512 builds","details":"split_image_check() in boot/bootutil/src/loader.c declares a fixed uint8_t loader_hash[32] buffer and passes it as the out_hash out-parameter to bootutil_img_validate(). That routine copies IMAGE_HASH_SIZE bytes into out_hash (memcpy(out_hash, hash, IMAGE_HASH_SIZE) in boot/bootutil/src/image_validate.c), where IMAGE_HASH_SIZE is a compile-time constant of 64 for MCUBOOT_SHA512 or 48 for MCUBOOT_SIGN_EC384/SHA-384 (boot/bootutil/include/bootutil/crypto/sha.h). The buffer tracks SHA-256 (32 bytes) while the copy length tracks the configured algorithm, so the write overruns the buffer by 16 or 32 bytes.\n\nThe overflow is only present in a non-default configuration: the legacy Mynewt split-image feature must be compiled (split_go()/split_image_check(), i.e. neither MCUBOOT_DIRECT_XIP nor MCUBOOT_RAM_LOAD), the digest must be larger than 32 bytes (MCUBOOT_SHA512 or MCUBOOT_SIGN_EC384), and MCUBOOT_SIGN_PURE must be off. split_go() is a public API with no caller inside MCUboot; it is invoked from a Mynewt application. In the default SHA-256 build there is no overflow.\n\nThe over-written bytes are the one-way digest of the loader image and the overflow length is fixed at build time, so the contents are not meaningfully attacker-controlled and the size is not attacker-chosen. The realistic impact is bounded, uncontrolled corruption of the bootloader's stack on the split-boot path, manifesting as instability or failed boot in the affected configuration rather than reliable code execution. The fix is to size loader_hash to IMAGE_HASH_SIZE and pass IMAGE_HASH_SIZE as the matching seed length.","aliases":["GHSA-vj6q-r752-fpqv"],"modified":"2026-11-14T02:47:33.737092222Z","published":"2026-11-13T00:23:02.120Z","database_specific":{"cwe_ids":["CWE-787"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/16xxx/CVE-2026-16671.json","cna_assigner":"zephyr"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/16xxx/CVE-2026-16671.json"},{"type":"ADVISORY","url":"https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-vj6q-r752-fpqv"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-16671"},{"type":"FIX","url":"https://github.com/mcu-tools/mcuboot/commit/9fb70f00173766d73cdadd82266bd61e4ddd0252"},{"type":"PACKAGE","url":"https://github.com/mcu-tools/mcuboot"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/mcu-tools/mcuboot","events":[{"introduced":"304fd41980ed929533b9f387dde1b463b0be5b90"},{"fixed":"725d63c9d5bc1bb572d802e7a768daf504186daf"},{"fixed":"9fb70f00173766d73cdadd82266bd61e4ddd0252"}],"database_specific":{"extracted_events":[{"strategy":"StandardRange","range":[{"introduced":"2.0.0"},{"fixed":"2.5.0"}],"source":"AFFECTED_FIELD"},{"source":"REFERENCES_COMMIT","range":[{"fixed":"9fb70f00173766d73cdadd82266bd61e4ddd0252"}]}]}}],"versions":["v2.4.0","v2.4.0-rc1","v2.3.0","v2.3.0-rc2","v2.3.0-rc1","v2.2.0","v2.2.0-rc2","v2.2.0-rc1","v2.1.0","v2.1.0-rc1","v2.0.0"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-16671.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L"}]}