DF-4168 — DC bounds all VBIOS walks by the image's self-declared size byte (bios[2]*512), not the allocated buffer length

• File: sys/dev/drm/amd/display/dc/bios/bios_parser2.c:1930 (bios_parser_construct: bios_size = bios[2] * 512)
• Bound consumer: sys/dev/drm/amd/display/dc/bios/bios_parser_helper.c:36-44 (bios_get_image: the only bounds check, offset + size < bp->bios_size)
• Allocation side (never plumbed into DC): sys/dev/drm/amd/amdgpu/amdgpu_bios.c:123-150 (amdgpu_read_bios: kzalloc(size) with the pci_map_rom size; check_atom_bios (:50-81) validates magic + ATOM pointer only, never cross-checks bios[2]*512), igp_read_bios_from_vram (256KB), amdgpu_read_bios_from_rom (AMD_VBIOS_LENGTH), ATRM (256KB)
• Class: heap out-of-bounds READ, CWE-125. Hardware-gated (AMD ASIC + crafted VBIOS image whose size byte exceeds the true allocation — small ROM BARs, vfio/QEMU romfile sizing, or a malicious device).

Verified via the verbatim-code rig (rig/)

The production construction + table-walk code was sed-extracted byte-identical from sys/ (gen_rig.sh), re-verified on the DragonFly guest against /usr/src/sys (check_verbatim.sh: 30 blocks identical to production + the fix-variant equivalence proofs), compiled on the guest, and driven with a crafted image: a fully valid ATOM ROM (header v2.2 @0x40, master data table v2_1 @0x20, displayobjectinfo v1_4 @0x60 — everything bios_parser_construct needs, all inside the 4096-byte "allocation") whose bios[2] = 0xFF claims 130,560 bytes — 31x the allocation.

Build / run (on the DragonFly guest)

cd rig && sh ./build.sh /usr/src
cd rig && sh ./run.sh

Modes

layout, size-mismatch (the claim itself), oob-guard (allocation ends at a PROT_NONE page; firmwareinfo/dce_info table offsets point past the allocation but inside the claimed size), oob-canary (readable "adjacent heap" region; tables crafted there with dce_refclk_10khz = 0x1234), guard-construct (the ROM-header pointer at image[0x48] points past the allocation — construct's OWN walk).

Expected output (see run.log / run.2.log)

Baseline (production code): - size-mismatch: construct SUCCEEDS; bp->base.bios_size = 130560 vs true allocation 4096 — every GET_IMAGE walk may read up to offset 130560 (ceiling ≈ 126 KB past this allocation) - oob-guard: SIGSEGV reading at mapping offset 4354 (= the firmwareinfo header byte at 0x1100+2), 258 bytes past the 4096-byte allocation, while the claimed bound (130560) happily admits the offset → OOB READ past the heap allocation - oob-canary: BP_RESULT_OK with crystal_frequency = 46600 — exactly 0x1234 × 10 read from offset 0x1300, 768 bytes past the allocation: adjacent-region bytes parsed into DC state (earlier run with plain 0x41 filler parsed 0x4141 → 167050 — whatever sits past the allocation becomes the reference clock) - guard-construct: SIGSEGV reading at offset 9474 (0x2500+2) — construct's own GET_IMAGE(atom_rom_header_v2_2, *0x48) walk (bios_parser2.c:1942) past the allocation

Fixed (-DAPPLY_DF4168_FIX = the bios_parser2.c + bios_parser_interface.h hunks of fix.diff, checker-proven; the harness plumbs init.bios_size = 4096, the role of fix.diff's amdgpu_dm.c/dc.c plumbing): - size-mismatch: bios_size clamped to 4096 - oob-guard / oob-canary: construct succeeds, the firmware-info walk returns BP_RESULT_BADBIOSTABLE, sentinel info struct untouched, no fault, no adjacent-region read on the identical image - guard-construct: construct rejects cleanly (GET_IMAGE → NULL), no fault

Verdict

Reproduced (verbatim-rig evidence class): the exact production code bounds every VBIOS walk by the attacker-supplied size byte and reads past the true heap allocation — guard-page fault proof plus adjacent-region canary proof. fix.diff (plumb the allocated length and clamp) eliminates it — A/B validated in the same rig. See VERDICT.md, verdict.json.

DF-4168 — VERDICT (verify run, 2026-10-15)

Status: REPRODUCED (verbatim-rig evidence class). The production construction + table-walk code, byte-identical to the running kernel's source, walks past the true heap allocation whenever the image's self- declared size byte exceeds it: guard-page SIGSEGV reads at offsets the claimed bound admits, and adjacent-region bytes are parsed into DC state. In-kernel execution is AMD-ASIC-gated on this guest (no AMD GPU — proven, see env.txt). Fix A/B validated in the same rig: fixed.

1. What was verified and how

Same evidence class as DF-4165/DF-4167 (siblings on this exact file): the guest cannot run amdgpu/dc (Bochs SVGA 0x1234:1111 only, sysctl dev.drm unknown, no drm/amdgpu KLDs — env.txt), so the actual production code was compiled into a guest-side harness:

• rig/gen_rig.sh sed-extracts, byte-identical from the read-only sys/ tree: bios_get_image (bios_parser_helper.c:36-44 — the only bounds check on the path), get_atom_data_table_revision (bios_parser2.c:133-151), bios_parser_get_firmware_info (:1119-1155) → get_firmware_info_v3_1 (:1157-1202) / get_firmware_info_v3_2 (:1204-1280) as the demonstration walk, bios_parser_construct (:1912-1992, the bios_size = bios[2] * 512 line at :1930) and firmware_parser_create (:1994-2009) — plus every struct they touch (atomfirmware.h tables verbatim under the production #pragma pack(1) at :207/:2934, rom header v2_2, master data table v2_1, displayobjectinfo v1_4, bp_init_data, dc_firmware_info).
• rig/check_verbatim.sh re-proved all 30 blocks byte-identical, run both against the host sys/ tree and on the guest against /usr/src/sys, the tree its running kernel (Jul 2 2026 build) was compiled from: ALL VERBATIM CHECKS PASSED (build.log). The checker additionally applies the bios_parser2.c hunk of fix.diff to the production construct and proves the APPLY_DF4168_FIX variant equals the patch result, and that the bp_init_data.bios_size member insert equals the bios_parser_interface.h hunk's additions. (The dc_types.h / amdgpu_dm.c / dc.c hunks are caller-side plumbing; the harness plays their role by filling init.bios_size with the true allocation length.)
• Harness shims touch nothing on the bounds path: minimized dc_bios/bios_parser (first-member layout, container_of identity), kzalloc→placement, vbios_funcs macro-mapped to a shim table whose single member dispatches to the verbatim bios_parser_get_firmware_info (so construct's bp->base.funcs = &vbios_funcs is a real dispatch); dal_firmware_parser_init_cmd_tbl / dal_bios_parser_init_cmd_tbl_helper2 (command-table pointer init — never touch bios_size or image bytes) and bios_parser_create_integrated_info (the integratedsysteminfo walk verified separately as DF-4165; returns NULL, which construct tolerates) are no-op shims, documented.

The crafted image is a fully valid minimal ATOM ROM — header v2_2 @0x40 (revision 2.2), master data table v2_1 @0x20 (firmwareinfo → 0x100 or 0x1100, dce_info → 0x200 or 0x1300, displayobjectinfo → 0x60, revision 1.4) — everything bios_parser_construct requires, all inside the 4096-byte allocation, with bios[2] = 0xFF.

2. Observed (run.log, stable across run.2.log)

• size-mismatch (the core claim): firmware_parser_create → bios_parser_construct SUCCEEDS; bp->base.bios_size = 130560 (from the image byte) vs true allocation 4096 — a 31x over-trust. Every subsequent GET_IMAGE / table walk is bounded by the claimed value: any offset < 130560 − sizeof(table) is admitted. Ceiling with bios[2] = 0xFF: reads up to 126 KB past this allocation (the finding's ~95 KB figure corresponds to a 32 KB true allocation; same mechanism).
• oob-guard: allocation [0,4096) ends at a PROT_NONE page; firmwareinfo @0x1100, dce_info @0x1300 (both past the allocation, inside the claimed 130560). Construct succeeds; the firmware-info walk (bios_parser_get_firmware_info → GET_IMAGE(header, 0x1100) passes 0x1100+4 < 130560 → get_atom_data_table_revision dereferences) → SIGSEGV READING at mapping offset 4354 = 0x1102 — 258 bytes past the 4096-byte allocation: OOB heap read in the production walk (rc=88 from the handler). In-kernel this is a read past the adev->bios kzalloc.
• oob-canary: the region past the allocation made readable and pre-filled 0x41, with the tables crafted there (dce_refclk_10khz = 0x1234 @0x1300): the walk returns BP_RESULT_OK with crystal_frequency = 46600 = 0x1234 × 10 read from 768 bytes past the allocation — adjacent-heap bytes parsed into DC's reference-clock state. (An earlier run with plain 0x41 filler parsed 0x4141 → 167050: whatever bytes follow the allocation become firmware "data".)
• guard-construct: image[0x48] (the ROM-header pointer) = 0x2500: construct's own GET_IMAGE(struct atom_rom_header_v2_2, *0x48) passes (0x2500+40 < 130560) and `get_atom_data_table_revision(&rom_header-

  table_header,…)(:1947) dereferences → **SIGSEGV` READING at offset 9474 = 0x2502**, past the allocation — construct itself walks OOB (bios_parser2.c:1942), not only the consumers.

Allocation-side facts confirmed by source (no rig needed): amdgpu_read_bios allocates kzalloc(size) with the pci_map_rom size (amdgpu_bios.c:130-141); check_atom_bios (:50-81) validates the 0x55AA magic and the ATOM signature only — it never compares bios[2]*512 against size; struct bp_init_data (bios_parser_interface.h:33-36) carries only the pointer, so the allocation length is never plumbed into DC — exactly the gap fix.diff closes.

3. Primitive and impact

Primitive: attacker-bounded OOB kernel heap reads — with a crafted image claiming 0xFF units, every table/record walk in bios_parser2 (and any DC consumer of bp->bios_size) may read up to 130,560 bytes past the base of a heap allocation that can be as small as the true ROM image (small ROM BARs; vfio/QEMU romfile where the BAR is sized independently of the image-size byte). Demonstrated: guard-page fault (crash-class when the past-end memory is unmapped) and silent adjacent-heap disclosure into driver-parsed state (reference clock, engine/memory clocks, table revisions). Gating: AMD ASIC presenting the crafted/oversized-claim ROM — the finding's threat model (flashed ROM, vfio-pci romfile=, malicious device); no unprivileged userland trigger.

Impact recorded as leak (CWE-125 OOB read; adjacent kernel heap contents are consumed as parser data). The crash flavor is also demonstrated (oob-guard, guard-construct) but reads are the primary primitive. No write primitive arises from this finding; DF-4165 covers the write side of this parser.

4. Fix validation (A/B, identical crafted image)

rig_fixed = same verbatim slice + exactly the bios_parser2.c clamp and the bp_init_data member of fix.diff (checker-proven), with the harness providing init.bios_size = 4096 (the role of fix.diff's amdgpu_dm.c / dc.c plumbing):

• size-mismatch: bios_size clamped to 4096;
• oob-guard: construct succeeds (in-allocation tables pass the clamped bound), the firmware-info walk returns BP_RESULT_BADBIOSTABLE (GET_IMAGE NULL → revision 0 → no dispatch), sentinel info struct untouched, no fault;
• oob-canary: BP_RESULT_BADBIOSTABLE, "info untouched (sentinel intact: yes), no table bytes parsed" — no adjacent-region read;
• guard-construct: GET_IMAGE rejects 0x2500 → construct returns false cleanly, no fault.

Baseline reads past the allocation, patched slice rejects out-of-allocation tables on the identical image → fix validated (fix_validation.log). Kernel-rebuild validation not performed (fix site executes in-kernel only on AMD ASICs absent from this guest; per the verbatim-rig protocol the fixed slice was A/B-validated in the same rig). fix.diff remains authored against the pristine read-only sys/ tree and was never applied there.

5. Honest limitations

• Demonstrated with production instructions and production struct layouts, but in a userland mapping standing in for the kernel heap; the allocation/claimed mismatch itself (small ROM BAR, vfio romfile sizing) is established by source reading (amdgpu_bios.c) plus the QEMU sizing argument, not by presenting a real undersized BAR to this guest.
• The walk demonstrated is firmwareinfo/dce_info and construct's rom-header read; the same claimed-size bound governs every other table walk in the file (object tables, encoder caps, board layout — and DF-4165's integratedsysteminfo), but each was not separately re-driven.
• The exfiltration path of the canary variant lands in DC-internal state (clocks parsed from adjacent heap); no direct copy-to-userspace of the OOB bytes was demonstrated — hence impact leak at the parsed-state-corruption/potential-information-influence level rather than a demonstrated userland info leak.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.