How UEFI Handles Malformed GPT and Hybrid MBR Disks

This article examines how UEFI firmware parsers process partition schemes, specifically addressing the mechanisms used to detect, validate, and recover from malformed GUID Partition Tables (GPT) and non-standard hybrid MBR layouts. It covers the defensive validation steps defined by the UEFI specification, the fallback pathways between primary and backup headers, how firmware treats legacy partition entries juxtaposed with GPT headers, and the security implications of parsing corrupt storage structures.

Standard GPT Validation Flow

The UEFI specification mandates a strict sequence of checks when scanning a block device to locate bootable partitions. The process begins at Logical Block Address 0 (LBA 0), which must contain a Protective Master Boot Record (PMBR). The parser checks the PMBR partition table for a partition record with an OS Type of 0xEE. If this structure is present and formatted according to spec, the parser advances to LBA 1 to inspect the Primary GPT Header.

To validate the Primary GPT Header, the parser performs several deterministic checks:

  1. Signature Verification: It checks for the 8-byte ASCII string "EFI PART".
  2. Header CRC32: It zeroes out the HeaderCRC32 field in a temporary buffer and computes the CRC32 checksum across the byte length specified by HeaderSize. The result must match the recorded CRC32.
  3. LBA Consistency: It confirms that the MyLBA field equals 1, and that FirstUsableLBA and LastUsableLBA fall within physical disk limits.
  4. Partition Array CRC32: It reads the partition entry array located at PartitionEntryLBA and verifies that the computed CRC32 matches PartitionEntryArrayCRC32.

Handling Malformed or Corrupt GPT Headers

When corruption occurs in a GPT layout, the firmware relies on structural redundancy. Every GPT-formatted drive includes a Primary GPT at the beginning of the disk and an Alternate (Secondary) GPT at the final LBA of the drive.

If the Primary GPT Header at LBA 1 fails any verification step—such as an invalid signature, an incorrect header CRC32, or a mismatched partition array checksum—the parser marks the primary structure as invalid. It then immediately attempts to read the Alternate GPT Header from the last logical block of the disk.

If the Alternate GPT Header is intact, passes its own CRC32 checks, and features a valid partition entry array, the UEFI firmware uses the backup data to construct the device path and mount the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In conformant implementations like TianoCore EDK II, the parser handles this recovery dynamically in memory. While the UEFI driver may permit the operating system to boot from the backup table, it generally leaves the physical repair of the primary table to administrative OS-level utilities.

If both the primary and backup headers fail validation, the GPT parser rejects the disk structure entirely, returning EFI_UNSUPPORTED or EFI_NOT_FOUND. At this point, the block device is rendered unbootable under standard UEFI routines.

Handling Hybrid MBR Configurations

A Hybrid MBR is a non-standard layout originally designed to allow dual-booting between legacy BIOS systems (which require an MBR) and UEFI systems (which require GPT). In a pure UEFI implementation, LBA 0 contains only a single 0xEE partition that spans either the size of the disk or the maximum 32-bit sector limit (0xFFFFFFFF). In a Hybrid MBR, LBA 0 contains up to three additional legacy MBR partition entries alongside the 0xEE entry, or defines a truncated 0xEE partition.

When a UEFI parser encounters a Hybrid MBR:

  • Detection: If the parser detects at least one partition of type 0xEE, it treats the disk as a GPT disk and bypasses all other legacy MBR slice entries.
  • Synchronization Hazards: UEFI partition drivers do not synchronize or reconcile MBR partition entries with GPT partition entries. If a user modifies partitions using a legacy MBR tool, the primary GPT remains unchanged. The UEFI firmware will only mount partitions defined inside the GPT array, ignoring any legacy partition boundaries defined in the MBR.
  • Compatibility Support Module (CSM) Fallback: On older firmware that incorporates a CSM, an ambiguous or malformed PMBR may cause the firmware boot manager to misclassify the drive as a legacy MBR disk. If the 0xEE marker is not strictly in the first slot or if it does not encompass the GPT structures, firmware with active CSM might prioritize legacy boot paths over native UEFI execution.

Defensive Parsing and Malformed Entry Handling

Modern UEFI implementations harden partition table parsing routines against structural exploits, such as integer overflows, overlapping boundaries, and infinite loops:

  • Entry Size and Count Validation: The parser calculates the total size of the partition entry array by multiplying NumberOfPartitionEntries by SizeOfPartitionEntry. Firmware validates that SizeOfPartitionEntry is an integer multiple of 128 (often checking specifically for values \(\ge 128\)) and that the multiplication does not trigger an integer overflow before allocating pool memory.
  • LBA Bounds Checking: Each individual partition entry contains a StartingLBA and an EndingLBA. Parsers enforce that StartingLBA <= EndingLBA, that both values reside strictly between FirstUsableLBA and LastUsableLBA, and that partition ranges do not extend beyond the actual disk capacity reported by the underlying EFI_BLOCK_IO_PROTOCOL.
  • Zeroed Entries: Unused partition entries are identified by a completely zeroed PartitionTypeGUID. The parser safely ignores these entries and continues iterating until NumberOfPartitionEntries is reached.

If an individual partition entry within an otherwise valid GPT contains impossible geometry (such as an inverted LBA range), modern implementations ignore that specific partition or decline to expose it via the device hierarchy, preventing subsequent filesystem drivers from processing corrupted storage bounds.