uefi-firmware-parser: ReadCLen() overruns the 510-entry mCLen heap array on crafted firmware

CVSS 9.8CVE-2026-54334Firmware, BMC & network fabriccurated

Impact

ReadCLen() reads a 9-bit count and loops without enforcing Index < NC, so it can write 511 entries into the 510-element heap array Sd->mCLen, and the CharC == 2 run-length path can push up to 531 zero writes through the same index. A crafted Tiano or EFI compressed section therefore corrupts heap memory in any pipeline that parses untrusted firmware images - vendor BIOS or BMC bundles ingested for validation, attestation or inventory. The parse crashes deterministically and the advisory allows for code execution depending on build and runtime details, in the account that owns the firmware pipeline. This is a separate flaw from the stack overflow in MakeTable() (CVE-2026-54333): different function, different allocation, though both ship fixed in 1.14. No running node's firmware is affected.

Who can reach it

Anyone who can supply a crafted firmware image to a parsing run - a tampered vendor blob, an upload into a firmware analysis service, or automated ingest of third-party images.

What to do

Upgrade uefi-firmware-parser to 1.14, which bounds the mCLen loop. A library bump and a restart of the importing service or job; no node or firmware maintenance. Meanwhile restrict parsing to trusted image sources and isolate the parser from firmware repositories and signing keys.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-54334 https://github.com/theopolis/uefi-firmware-parser/security/advisories/GHSA-hm2w-vr2p-hq7w https://github.com/theopolis/uefi-firmware-parser/commit/bf3dfaa8a05675bae6ea0cbfa082ddcebfcde23e https://github.com/theopolis/uefi-firmware-parser/releases/tag/v1.14

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.