DF-3744 — Unbounded LVDS mode-patch record walk + fake-EDID copy read past the VBIOS image buffer (conditional userspace leak)

Severity: Medium · CWE: CWE-125 Out-of-bounds Read · File: sys/dev/drm/radeon/radeon_atombios.c:1691-1752

What this is

radeon_atombios_get_lvds_info() walks the mode-patch record table with while (*record != ATOM_RECORD_END_TYPE) (:1706) — the only exit conditions are the sentinel byte, known record types stepping by fixed sizes or ucFakeEDIDLength, or an unknown type. Nothing bounds the walk to the VBIOS image: usModePatchTableOffset is an unvalidated u16 (:1697-1705) and record strides are attacker-chosen, so the walk crosses the end of the rdev->bios kmalloc'd image and keeps reading heap. The fake-EDID branch (:1717-1737) kmallocs max(128,len) and memcpy's len (<=255) bytes from record+2 — with the record placed at the image end this copies up to 255 bytes of ADJACENT KERNEL HEAP into bios_hardcoded_edid; if drm_edid_is_valid() passes (checksum 1/256 odds on uncontrolled bytes; guaranteed for the in-image part), those bytes become the connector EDID blob, readable from userspace (DRM_IOCTL_MODE_GETCONNECTOR). Harness on guest: record at image end, len=200 -> 200/200 bytes read beyond image; walk continues 201+ bytes past end until garbage type. Kernel path unreachable on this guest.

Reproduce

./build.sh    # cc -O1 -g -Wall -o <bin> harness_lvds.c   (DragonFly guest, cc 8.3)
./run.sh      # expected: fake-EDID len=200: 200/200 bytes read beyond image end; walk continues past end until garbage record type; exit_code=0

The harness replicates the kernel parse arithmetic VERBATIM (cited path:line) against a synthetic crafted-VBIOS buffer with canary-guarded destinations.

Guest / environment

Guest has NO AMD/radeon GPU (virtio-only); /boot/kernel/radeon.ko exists (code shipped in the default install) but cannot attach, so the kernel code path is unreachable at runtime on this guest. Evidence is source-level certainty (path:line traced) plus a verbatim-arithmetic userland harness compiled and executed on the guest (build.log/run.log). See env.txt (uname, cc, kldstat, /boot/kernel/radeon.ko presence).

Fix

bound the walk to the BIOS image (requires tracking the image length in atom_context) — see fix.diff (authored after verification; never applied to sys/).

DF-3744 — Unbounded LVDS mode-patch record walk + fake-EDID copy read past the VBIOS image buffer (conditional userspace leak)

Severity: Medium · CWE: CWE-125 Out-of-bounds Read · File: sys/dev/drm/radeon/radeon_atombios.c:1691-1752

What this is

radeon_atombios_get_lvds_info() walks the mode-patch record table with while (*record != ATOM_RECORD_END_TYPE) (:1706) — the only exit conditions are the sentinel byte, known record types stepping by fixed sizes or ucFakeEDIDLength, or an unknown type. Nothing bounds the walk to the VBIOS image: usModePatchTableOffset is an unvalidated u16 (:1697-1705) and record strides are attacker-chosen, so the walk crosses the end of the rdev->bios kmalloc'd image and keeps reading heap. The fake-EDID branch (:1717-1737) kmallocs max(128,len) and memcpy's len (<=255) bytes from record+2 — with the record placed at the image end this copies up to 255 bytes of ADJACENT KERNEL HEAP into bios_hardcoded_edid; if drm_edid_is_valid() passes (checksum 1/256 odds on uncontrolled bytes; guaranteed for the in-image part), those bytes become the connector EDID blob, readable from userspace (DRM_IOCTL_MODE_GETCONNECTOR). Harness on guest: record at image end, len=200 -> 200/200 bytes read beyond image; walk continues 201+ bytes past end until garbage type. Kernel path unreachable on this guest.

Reproduce

./build.sh    # cc -O1 -g -Wall -o <bin> harness_lvds.c   (DragonFly guest, cc 8.3)
./run.sh      # expected: fake-EDID len=200: 200/200 bytes read beyond image end; walk continues past end until garbage record type; exit_code=0

The harness replicates the kernel parse arithmetic VERBATIM (cited path:line) against a synthetic crafted-VBIOS buffer with canary-guarded destinations.

Guest / environment

Guest has NO AMD/radeon GPU (virtio-only); /boot/kernel/radeon.ko exists (code shipped in the default install) but cannot attach, so the kernel code path is unreachable at runtime on this guest. Evidence is source-level certainty (path:line traced) plus a verbatim-arithmetic userland harness compiled and executed on the guest (build.log/run.log). See env.txt (uname, cc, kldstat, /boot/kernel/radeon.ko presence).

Fix

bound the walk to the BIOS image (requires tracking the image length in atom_context) — see fix.diff (authored after verification; never applied to sys/).

VERDICT — DF-3744

Status: inconclusive (source-certain; harness-reproduced arithmetic; kernel path unreachable on this guest) reproduced: 0 (in-kernel) — harness demonstration: YES Impact on real hardware: Medium — CWE-125 Out-of-bounds Read

Finding

radeon_atombios_get_lvds_info() walks the mode-patch record table with while (*record != ATOM_RECORD_END_TYPE) (:1706) — the only exit conditions are the sentinel byte, known record types stepping by fixed sizes or ucFakeEDIDLength, or an unknown type. Nothing bounds the walk to the VBIOS image: usModePatchTableOffset is an unvalidated u16 (:1697-1705) and record strides are attacker-chosen, so the walk crosses the end of the rdev->bios kmalloc'd image and keeps reading heap. The fake-EDID branch (:1717-1737) kmallocs max(128,len) and memcpy's len (<=255) bytes from record+2 — with the record placed at the image end this copies up to 255 bytes of ADJACENT KERNEL HEAP into bios_hardcoded_edid; if drm_edid_is_valid() passes (checksum 1/256 odds on uncontrolled bytes; guaranteed for the in-image part), those bytes become the connector EDID blob, readable from userspace (DRM_IOCTL_MODE_GETCONNECTOR). Harness on guest: record at image end, len=200 -> 200/200 bytes read beyond image; walk continues 201+ bytes past end until garbage type. Kernel path unreachable on this guest.

Why not reproduced in-kernel

The QEMU guest is virtio-only (no AMD GPU): pciconf -l shows no 1002 device; kldstat shows radeon not loaded. /boot/kernel/radeon.ko exists (the vulnerable code ships in the default install) but cannot attach, so radeon_atombios.c parse paths never execute here. All conclusions are source-level (path:line above) plus the on-guest harness (harness_lvds.c).

Harness result

Command: ./run.sh (after ./build.sh) Expected/observed: fake-EDID len=200: 200/200 bytes read beyond image end; walk continues past end until garbage record type; exit_code=0 Full logs: build.log, run.log.

Impact / exploit chain

crafted LVDS_Info usModePatchTableOffset + fake-EDID record at image tail -> 200+ B heap OOB read copied into bios_hardcoded_edid -> (checksum luck) EDID blob exposed to userspace; otherwise walk continues OOB -> crash

Fix

bound the walk to the BIOS image (requires tracking the image length in atom_context) — fix.diff.

Honest notes

• DF-3744 does NOT re-report pass-1 findings DF-1198/1199/1200 (power-table state_index mismatch, asic_ss_info underflow, power-table indices) — different functions/tables/fields.
• fix validation not possible on this guest (no hardware); fix.diff is source-authored only.

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.

VERDICT — DF-3744

Status: inconclusive (source-certain; harness-reproduced arithmetic; kernel path unreachable on this guest) reproduced: 0 (in-kernel) — harness demonstration: YES Impact on real hardware: Medium — CWE-125 Out-of-bounds Read

Finding

radeon_atombios_get_lvds_info() walks the mode-patch record table with while (*record != ATOM_RECORD_END_TYPE) (:1706) — the only exit conditions are the sentinel byte, known record types stepping by fixed sizes or ucFakeEDIDLength, or an unknown type. Nothing bounds the walk to the VBIOS image: usModePatchTableOffset is an unvalidated u16 (:1697-1705) and record strides are attacker-chosen, so the walk crosses the end of the rdev->bios kmalloc'd image and keeps reading heap. The fake-EDID branch (:1717-1737) kmallocs max(128,len) and memcpy's len (<=255) bytes from record+2 — with the record placed at the image end this copies up to 255 bytes of ADJACENT KERNEL HEAP into bios_hardcoded_edid; if drm_edid_is_valid() passes (checksum 1/256 odds on uncontrolled bytes; guaranteed for the in-image part), those bytes become the connector EDID blob, readable from userspace (DRM_IOCTL_MODE_GETCONNECTOR). Harness on guest: record at image end, len=200 -> 200/200 bytes read beyond image; walk continues 201+ bytes past end until garbage type. Kernel path unreachable on this guest.

Why not reproduced in-kernel

The QEMU guest is virtio-only (no AMD GPU): pciconf -l shows no 1002 device; kldstat shows radeon not loaded. /boot/kernel/radeon.ko exists (the vulnerable code ships in the default install) but cannot attach, so radeon_atombios.c parse paths never execute here. All conclusions are source-level (path:line above) plus the on-guest harness (harness_lvds.c).

Harness result

Command: ./run.sh (after ./build.sh) Expected/observed: fake-EDID len=200: 200/200 bytes read beyond image end; walk continues past end until garbage record type; exit_code=0 Full logs: build.log, run.log.

Impact / exploit chain

crafted LVDS_Info usModePatchTableOffset + fake-EDID record at image tail -> 200+ B heap OOB read copied into bios_hardcoded_edid -> (checksum luck) EDID blob exposed to userspace; otherwise walk continues OOB -> crash

Fix

bound the walk to the BIOS image (requires tracking the image length in atom_context) — fix.diff.

Honest notes

• DF-3744 does NOT re-report pass-1 findings DF-1198/1199/1200 (power-table state_index mismatch, asic_ss_info underflow, power-table indices) — different functions/tables/fields.
• fix validation not possible on this guest (no hardware); fix.diff is source-authored only.

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.