DF-3746 — VoltageObjectInfo walkers trust self-declared sizes — OOB heap reads, v1 stride bug, and unbounded leakage-array indices

Severity: Medium · CWE: CWE-125 Out-of-bounds Read · File: sys/dev/drm/radeon/radeon_atombios.c:3382-3431, 3237-3280

What this is

The voltage-object family reads past the VBIOS image on self-declared data: (1) atom_lookup_voltage_object_v1/v2/v3 (:3382-3431) walk bounded only by the table's own usStructureSize (u16) — size=0xFFF8 walks ~16k objects over a 64-byte table and past the image (harness: 16290 OOB reads); returned OOB objects are then dereferenced by radeon_atom_get_max/min_voltage, get_voltage_step, get_svi2_info. (2) v1 advance bug: offset += offsetof(...)+ucNumOfVoltageEntries BYTES while entries are VOLTAGE_LUT_ENTRY=4 bytes (:3393-3394) — v2 correctly multiplies by sizeof (:3410-3411) — so v1 mis-parses every subsequent object. (3) radeon_atom_get_leakage_vddc_based_on_leakage_params checks only size<sizeof(header) (:3237) then indexes vddc_buf[j*ucElbVDDC_Num+i] with two BIOS u8 counts — up to element 65024 (~130 KB past the array base, far past any VBIOS image). Kernel path unreachable on this guest.

Reproduce

./build.sh    # cc -O1 -g -Wall -o <bin> harness_voltobj.c   (DragonFly guest, cc 8.3)
./run.sh      # expected: v1 walk with self-declared size 0xFFF8 over a 64-byte table: 16290 reads past image end; stride bug: 7 vs 16 bytes for 3 entries; leakage index 64769 -> 129538 B past array; 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 walks by the image length (bios_size plumbing) and fix the v1 stride — see fix.diff (authored after verification; never applied to sys/).

DF-3746 — VoltageObjectInfo walkers trust self-declared sizes — OOB heap reads, v1 stride bug, and unbounded leakage-array indices

Severity: Medium · CWE: CWE-125 Out-of-bounds Read · File: sys/dev/drm/radeon/radeon_atombios.c:3382-3431, 3237-3280

What this is

The voltage-object family reads past the VBIOS image on self-declared data: (1) atom_lookup_voltage_object_v1/v2/v3 (:3382-3431) walk bounded only by the table's own usStructureSize (u16) — size=0xFFF8 walks ~16k objects over a 64-byte table and past the image (harness: 16290 OOB reads); returned OOB objects are then dereferenced by radeon_atom_get_max/min_voltage, get_voltage_step, get_svi2_info. (2) v1 advance bug: offset += offsetof(...)+ucNumOfVoltageEntries BYTES while entries are VOLTAGE_LUT_ENTRY=4 bytes (:3393-3394) — v2 correctly multiplies by sizeof (:3410-3411) — so v1 mis-parses every subsequent object. (3) radeon_atom_get_leakage_vddc_based_on_leakage_params checks only size<sizeof(header) (:3237) then indexes vddc_buf[j*ucElbVDDC_Num+i] with two BIOS u8 counts — up to element 65024 (~130 KB past the array base, far past any VBIOS image). Kernel path unreachable on this guest.

Reproduce

./build.sh    # cc -O1 -g -Wall -o <bin> harness_voltobj.c   (DragonFly guest, cc 8.3)
./run.sh      # expected: v1 walk with self-declared size 0xFFF8 over a 64-byte table: 16290 reads past image end; stride bug: 7 vs 16 bytes for 3 entries; leakage index 64769 -> 129538 B past array; 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 walks by the image length (bios_size plumbing) and fix the v1 stride — see fix.diff (authored after verification; never applied to sys/).

VERDICT — DF-3746

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

The voltage-object family reads past the VBIOS image on self-declared data: (1) atom_lookup_voltage_object_v1/v2/v3 (:3382-3431) walk bounded only by the table's own usStructureSize (u16) — size=0xFFF8 walks ~16k objects over a 64-byte table and past the image (harness: 16290 OOB reads); returned OOB objects are then dereferenced by radeon_atom_get_max/min_voltage, get_voltage_step, get_svi2_info. (2) v1 advance bug: offset += offsetof(...)+ucNumOfVoltageEntries BYTES while entries are VOLTAGE_LUT_ENTRY=4 bytes (:3393-3394) — v2 correctly multiplies by sizeof (:3410-3411) — so v1 mis-parses every subsequent object. (3) radeon_atom_get_leakage_vddc_based_on_leakage_params checks only size<sizeof(header) (:3237) then indexes vddc_buf[j*ucElbVDDC_Num+i] with two BIOS u8 counts — up to element 65024 (~130 KB past the array base, far past any VBIOS image). 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_voltobj.c).

Harness result

Command: ./run.sh (after ./build.sh) Expected/observed: v1 walk with self-declared size 0xFFF8 over a 64-byte table: 16290 reads past image end; stride bug: 7 vs 16 bytes for 3 entries; leakage index 64769 -> 129538 B past array; exit_code=0 Full logs: build.log, run.log.

Impact / exploit chain

crafted VoltageObjectInfo/ASIC_ProfilingInfo tables -> OOB heap reads at DPM init -> wrong voltage objects used (mis-programmed voltages) and/or crash

Fix

bound walks by the image length (bios_size plumbing) and fix the v1 stride — fix.diff.

Honest notes

• DF-3746 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-3746

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

The voltage-object family reads past the VBIOS image on self-declared data: (1) atom_lookup_voltage_object_v1/v2/v3 (:3382-3431) walk bounded only by the table's own usStructureSize (u16) — size=0xFFF8 walks ~16k objects over a 64-byte table and past the image (harness: 16290 OOB reads); returned OOB objects are then dereferenced by radeon_atom_get_max/min_voltage, get_voltage_step, get_svi2_info. (2) v1 advance bug: offset += offsetof(...)+ucNumOfVoltageEntries BYTES while entries are VOLTAGE_LUT_ENTRY=4 bytes (:3393-3394) — v2 correctly multiplies by sizeof (:3410-3411) — so v1 mis-parses every subsequent object. (3) radeon_atom_get_leakage_vddc_based_on_leakage_params checks only size<sizeof(header) (:3237) then indexes vddc_buf[j*ucElbVDDC_Num+i] with two BIOS u8 counts — up to element 65024 (~130 KB past the array base, far past any VBIOS image). 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_voltobj.c).

Harness result

Command: ./run.sh (after ./build.sh) Expected/observed: v1 walk with self-declared size 0xFFF8 over a 64-byte table: 16290 reads past image end; stride bug: 7 vs 16 bytes for 3 entries; leakage index 64769 -> 129538 B past array; exit_code=0 Full logs: build.log, run.log.

Impact / exploit chain

crafted VoltageObjectInfo/ASIC_ProfilingInfo tables -> OOB heap reads at DPM init -> wrong voltage objects used (mis-programmed voltages) and/or crash

Fix

bound walks by the image length (bios_size plumbing) and fix the v1 stride — fix.diff.

Honest notes

• DF-3746 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.