Description

UEFI Firmware Parser parses BIOS, Intel ME, and UEFI firmware structures including volumes, file systems, and files. Prior to 1.14, ReadCLen() in uefi_firmware/compression/Tiano/Decompress.c reads Number from GetBits(Sd, CBIT) with CBIT = 9 and can obtain 511 entries for the 510-element Sd->mCLen heap array because its loop does not enforce Index < NC. The CharC == 2 run-length path can additionally request up to 531 zero writes through Sd->mCLen[Index++] = 0. The normal CompressedSection.process() to efi_compressor.TianoDecompress() to TianoDecompress() to DecodeC() to ReadCLen() parsing path therefore permits crafted Tiano or EFI compressed firmware to corrupt heap memory, deterministically crash the parsing process, and potentially execute code depending on build and runtime details. This issue is fixed in version 1.14.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-14T20:16:46.143Z",
  "pubdate": "2026-09-14T20:16:46.143Z",
  "executiveSummary": "The UEFI Firmware Parser library, prior to version 1.14, contains a critical heap-based buffer overflow vulnerability within its Tiano/EFI decompression logic.\nThis vulnerability is rooted in an improper boundary check during the processing of compressed firmware structures, specifically within the ReadCLen() function.\nAn attacker can craft malicious UEFI or Tiano compressed firmware images to trigger this flaw, leading to heap memory corruption.\nSuccessful exploitation results in a deterministic crash of the parsing process (Denial of Service) or potential arbitrary code execution, contingent upon the specific build environment and runtime memory layout.\nThe vulnerability affects the parsing component of the software and requires the application to process a maliciously crafted firmware file.\nGiven that parsing tools often run with elevated privileges or interact with hardware-adjacent firmware, the risk implication is high, potentially allowing an attacker to compromise the integrity of the analysis environment.",
  "technicalDetails": "The vulnerability exists within uefi_firmware/compression/Tiano/Decompress.c in the ReadCLen() function, which is responsible for parsing compression metadata. The root cause is an out-of-bounds heap write due to insufficient input validation.\nSpecifically, the function utilizes the GetBits() utility to fetch a 'Number' value from the compressed stream using a constant CBIT = 9. This operation can return a value up to 511. This value is used as an index into the Sd->mCLen array, which is statically allocated with a size of only 510 elements (NC). The implementation fails to enforce an 'Index < NC' constraint, allowing the logic to write outside the allocated memory bounds of the heap-allocated structure.\nFurthermore, the CharC == 2 run-length path exacerbates this condition by permitting the application to request up to 531 zero-write operations using the statement 'Sd->mCLen[Index++] = 0'. This enables an attacker to perform a larger sequential write overflow beyond the initial index violation.\nThe exploitation path follows the sequence: CompressedSection.process() -> efi_compressor.TianoDecompress() -> TianoDecompress() -> DecodeC() -> ReadCLen(). When the parser encounters a crafted firmware image containing these malformed compression parameters, it processes the header information and subsequently overflows the heap.\nBy controlling the values provided in the compressed firmware bitstream, an attacker can precisely overwrite adjacent heap metadata or function pointers. While the primary immediate impact is a memory corruption crash, the overflow provides primitives necessary for heap grooming and subsequent code execution in environments where exploit mitigations like ASLR or DEP may be bypassed or absent.\nThis vulnerability does not require authentication, as the attack vector is a malformed file format parsed by the utility. The exploitation occurs during the standard parsing workflow, making it a passive-to-active threat depending on whether the parser is used as a standalone tool or as a library integrated into a larger firmware analysis pipeline."
}