DF-4121 — parse_sdvo_panel_data: unchecked VBT SDVO panel_type (0-255) indexes BDB_SDVO_PANEL_DTDS -> OOB read up to ~4.6 KB past the block

• File: sys/dev/drm/i915/intel_bios.c
• Lines: 363-381 Severity: Medium Confidence: certain
• Status: reproduced (impact: leak) — hardware-gated crafted-VBIOS/firmware threat model; harness-reproduced on the DragonFly guest.

Summary

intel_bios.c:363-381: parse_sdvo_panel_data() takes index from BDB_SDVO_LVDS_OPTIONS->panel_type (u8, 0..255) — or from the root-only module param — with NO bounds check, unlike its sibling parse_lfp_panel_data() (intel_bios.c:229 rejects panel_type > 0xf). fill_detail_timing_data() then reads sizeof(struct lvds_dvo_timing)=18 bytes at dvo_timing + index (intel_bios.c:381): offset 25518=4590..4608 past the BDB_SDVO_PANEL_DTDS data pointer. find_section() only guarantees the block* fits inside bdb_size; the DTDS block may legally be 1 DTD (18 bytes) or even 0 bytes, so the read runs up to ~4.6 KB past the end of the bdb — i.e. past the end of the kmemdup'd i915_vbt_firmware heap buffer, or across the opregion/PCI-ROM mapping. The parsed values become dev_priv->vbt.sdvo_lvds_vbt_mode (a display mode later merged into connector mode lists / debugfs).

Reproduce (harness)

./build.sh && ./run.sh — exit 77 = OOB/div0 confirmed by verbatim kernel code; -p run = proposed fix, exit 0.

Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

DF-4121 verdict — parse_sdvo_panel_data: unchecked VBT SDVO panel_type (0-255) indexes BDB_SDVO_PANEL_DTDS -> OOB read up to ~4.6 KB past the block

Reproduced? — reproduced (leak)

Harness-reproduced on the DragonFly guest: a 97-byte crafted VBT that passes intel_bios_is_valid_vbt() verbatim, with BDB_SDVO_LVDS_OPTIONS.panel_type=255 and an 18-byte BDB_SDVO_PANEL_DTDS as the last block, drives the verbatim parse_sdvo_panel_data indexing into a PROT_NONE guard page — SIGSEGV at dvo_timing+4590 (run.log: offset +4673 from buffer base, exit 77, stable across 3 runs). Hardware-gated on real i915 (VBT comes from firmware/opROM/ROM per the crafted-VBIOS threat model); the primitive is an out-of-bounds read whose values are stored as the SDVO panel mode.

Root cause (path:line)

intel_bios.c:363-381: parse_sdvo_panel_data() takes index from BDB_SDVO_LVDS_OPTIONS->panel_type (u8, 0..255) — or from the root-only module param — with NO bounds check, unlike its sibling parse_lfp_panel_data() (intel_bios.c:229 rejects panel_type > 0xf). fill_detail_timing_data() then reads sizeof(struct lvds_dvo_timing)=18 bytes at dvo_timing + index (intel_bios.c:381): offset 25518=4590..4608 past the BDB_SDVO_PANEL_DTDS data pointer. find_section() only guarantees the block* fits inside bdb_size; the DTDS block may legally be 1 DTD (18 bytes) or even 0 bytes, so the read runs up to ~4.6 KB past the end of the bdb — i.e. past the end of the kmemdup'd i915_vbt_firmware heap buffer, or across the opregion/PCI-ROM mapping. The parsed values become dev_priv->vbt.sdvo_lvds_vbt_mode (a display mode later merged into connector mode lists / debugfs).

Chain

crafted VBT (opregion RVDA / mailbox-4 / PCI ROM / i915_vbt_firmware) -> intel_bios_init -> parse_sdvo_panel_data -> fill_detail_timing_data(dvo_timing+255) -> OOB read up to +4608 past block

Kernel refs

• sys/dev/drm/i915/intel_bios.c:363
• sys/dev/drm/i915/intel_bios.c:370
• sys/dev/drm/i915/intel_bios.c:381
• sys/dev/drm/i915/intel_bios.c:229
• sys/dev/drm/i915/intel_vbt_defs.h:523
• sys/dev/drm/i915/intel_vbt_defs.h:626

Fix

Guard added after acquiring index from either source (VBT or module param), mirroring parse_lfp_panel_data:229. Harness -p mode implements exactly this check and rejects panel_type 255 without any DTD read (fix_run.log).

fix.diff applies cleanly against the read-only sys/ tree (2-file for DF-4125; note the radeon_pm.c hunk also needs dpm_failed_unlock: mutex_unlock(&rdev->pm.mutex); added to the existing dpm_failed label path — spelled out here since the label does not exist in the unfixed tree). Kernel-level fix validation is not possible on this guest (no i915/RV6xx devices; the drivers never attach in QEMU); harness-level fix validation IS included: the -p runs exercise the patched parse logic against the identical crafted input and exit 0 (fix_run.log).

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.