DF-3619 VERDICT — Heap OOB write in ci_get_svi2_voltage_table

Bottom line

Real bug, source-certain; runtime inconclusive on this guest (no AMD GPU).

The sink is ci_get_svi2_voltage_table() at sys/dev/drm/amd/amdgpu/ci_dpm.c:2264-2268:

voltage_table->count = voltage_dependency_table->count;      /* u8 from VBIOS, ≤255 */
for (i = 0; i < voltage_table->count; i++) {
        voltage_table->entries[i].value = voltage_dependency_table->entries[i].v;
        voltage_table->entries[i].smio_low = 0;
}

entries[] is fixed at MAX_VOLTAGE_ENTRIES == 32 (sys/dev/drm/amd/amdgpu/amdgpu_atombios.h:119-133). The count comes from amdgpu_parse_clk_voltage_dep_table() (sys/dev/drm/amd/amdgpu/amdgpu_dpm.c:285-302), which trusts the u8 ucNumEntries from the VBIOS PowerPlay table — up to 255, fully attacker-chosen in the crafted-VBIOS model. The GPIO-LUT path (amdgpu_atombios_get_voltage_table, amdgpu_atombios.c:1539-1540) does bound-check > MAX_VOLTAGE_ENTRIES; the SVI2 path does not — that asymmetry is the bug.

Reachability (traced)

• ci_dpm_init() (ci_dpm.c:6017-6041): voltage_control/vddci_control/mvdd_control become CISLANDS_VOLTAGE_CONTROL_BY_SVID2 when the VBIOS has SVID2 voltage objects — attacker includes them.
• ci_dpm_hw_init() → ci_dpm_enable() (ci_dpm.c:5300-5307) → ci_construct_voltage_tables() (ci_dpm.c:2273-2333) → the three ci_get_svi2_voltage_table() calls (2285/2303/2321) — the copy happens before the ci_trim_voltage_table_to_fit_state_table() calls (2292-2294 / 2310-2312 / 2328-2330) that reduce the count to SMU7_MAX_LEVELS_{VDDC,VDDCI,MVDD} = 8/4/4. Trims cannot undo the overflow.
• Also re-entered on every resume (ci_dpm_resume → ci_dpm_enable).

Overflow geometry (proven by executing the exact struct layouts on the guest)

struct ci_power_info tail (ci_dpm.h:230-297): the three 268-byte atom_voltage_tables are followed by ulv, pointers, caps, and driver-state structs (392 more bytes to the end of the object).

Write pattern per 8-byte slot: u16 attacker value at +0 (VBIOS usVoltage), u32 0 at +4. Clobbers in-object members including the powertune_defaults pointer (forged to 0x0000beef00000000 in the live guard test → wild pointer deref in ci_populate_svi_load_line, ci_dpm.c:445-448), and past the allocation into adjacent heap for the vddci/mvdd variants.

Exploit chain (why this matters beyond a panic)

In the crafted-VBIOS threat model the attacker additionally controls heap grooming timing at driver bind (kzalloc order is deterministic during amdgpu init). A count in the 82-255 range yields a linear heap overwrite of up to ~1.4 KB with 2 controlled bytes per 8 — sufficient to corrupt adjacent allocations' length fields/pointers toward UAF/arb-write, though the u32-zero-every-8-bytes pattern makes it markedly harder than a dense overwrite. At minimum: reliable kernel memory corruption / panic at boot.

Verification narrative

• Guest: DragonFly dfbsd 6.5-DEVELOPMENT #0 ... x86_64; virtio-only; vgapci0 chip=0x11111234 (ramfb) — no AMD ASIC → ci_dpm unreachable at runtime → status inconclusive (not false-positive).
• /boot/kernel/amdgpu.ko present (124,519,320 bytes) and loads cleanly ([drm] amdgpu kernel modesetting enabled.) — module-presence check done. (Unloading the 124 MB module wedges the DragonFly linker; guest was reset with vm.sh reset with-src afterward.)
• The logic/geometry PoC (ci_svi2_overflow.c) replicates the exact member sequence of ci_dpm.h:230-297 + amdgpu_atombios.h structs and the exact sink loop, compiled and executed on the guest (build.log/run.log): confirms 1784 bytes past entries[32], past-object thresholds 149/116/82, and 48/64 guard bytes corrupted behind the allocation in the live run.

Fix validation

Not possible on this guest (hardware absent): fix_status: not_testable. fix.diff adds the same > MAX_VOLTAGE_ENTRIES → -EINVAL bound the GPIO path already has.

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.