gptinit() accepts any CRC-self-consistent LBA1 block as a GPT header: hdr_sig ("EFI PART"), hdr_revision, and the partition-array CRC (hdr_crc_table) are never validated
| Field | Value |
|---|---|
| ID | DF-2964 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-345 |
| File | sys/kern/subr_diskgpt.c |
| Lines | 108-125, 131-144, 186-221 |
| Area | kern/disk |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
The header sanity check validates only hdr_size bounds and the hdr_crc_self CRC. The spec-mandated signature ("EFI PART"), hdr_revision, hdr_lba_self==1, and hdr_crc_table (CRC32 over the partition-entry array) are never checked: hdr_crc_table is not read anywhere in the file, so the 16KB entry array consumed at :186-221 is taken with zero integrity verification. Any block whose first hdr_size bytes CRC to the stored value is parsed as a GPT. Under the crafted-media threat model the attacker controls the table bytes anyway, so CRC checks add no security boundary — spec-compliance/ robustness hardening gap; all consumed fields are independently bounds-checked, no privilege or memory-safety impact. Observed incidentally during DF-2963 verification (variant image with wrong hdr_crc_table/garbage hdr_sig still probes identically). Fix: require GPT_HDR_SIG + validate the table CRC (row diff).
Timeline
- 2026-09-02 Discovered during pass-2 audit of subr_diskgpt.c (GLM 5.3).
No comments yet.