CVE-2026-128091

When MCUboot is built with the TinyCrypt crypto backend (MCUBOOT USE TINYCRYPT), bootutil aes ctr drop() in boot/bootutil/include/bootutil/crypto/aes ctr tinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tc aes key sched struct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here.

As a result, boot state clear(), which boot go() calls before handing off to the application, left the image's AES content-encryption key schedule in the static boot data state. This is the case after an encrypted upgrade in single-image builds, where boot enc zeroize() is not called. boot decrypt key() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOT ENC IMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port.

The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutil wipe memory().