Arm Trusted Firmware-A BL1/BL2 boot stages on platforms that load firmware from a Firmware Image Package (FIP)

UnscoredCVE-2026-34878Firmware, BMC & network fabricTFV-15FIP ToC offset validationcurated

Impact

FIP headers are not signed, so BL1/BL2 parse attacker-influenceable metadata before authentication happens. Bad offsets and lengths make the loader read from secure memory mapped in the EL3 translation regime and land that data in non-secure memory. That is a pre-authentication leak of secure-world contents at boot - keys, secure heap, whatever is mapped. For a bare-metal provider this is a tenant-handoff problem: a tenant who can write the boot FIP (firmware update path, A/B slot, provisioning share) gets to exfiltrate secure-world state on the next boot for the next tenant.

Who can reach it

An attacker who can modify or supply the FIP image the platform boots from - anyone with the firmware-update path, a writable boot partition, or control of the provisioning pipeline. On bare-metal GPU rental that is the previous tenant if you do not verify firmware between handoffs.

What to do

Update TF-A past commits 48351 and 49485 (strict ToC bounds validation, overflow-safe arithmetic, short-read detection) and rebuild BL1/BL2 for the platform. That is an OEM-shipped firmware build, flashed to each node, reboot and drain. Independently: treat the FIP as tenant-writable until proven otherwise, and re-verify or re-flash boot firmware from a known-good image at every tenant handoff rather than relying on the parser being safe.

References

https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/security-advisory-tfv-15.html

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.