DF-4395 VERDICT — vega10 dcefclk pioneer-path heap OOB write

Status: reproduced (harness) | impact: corruption | confidence: certain

Root cause (path:line)

get_dcefclk_voltage_dependency_table() in sys/dev/drm/amd/powerplay/hwmgr/vega10_processpptables.c:

• Line 709 asserts only ucNumEntries != 0 — a u8 the VBIOS image fully controls (up to 255); nothing validates it against the image size (that systemic gap is DF-4396).
• Lines 718-726 — the pioneer workaround: when adev->pdev->device == 0x6863 && rev_id == 0 and entries[ucNumEntries-1].ulClk < 90000, num_entries = min(ucNumEntries + 1, NUM_DSPCLK_LEVELS=8).
• Lines 729-733 — the destination kzalloc is sized by num_entries (4 + 28 * num_entries; phm_ppt_v1_clock_voltage_dependency_record is 28 bytes — hwmgr_ppt.h:31-45).
• Lines 740-745 — the copy loop runs for (i = 0; i < clk_dep_table->ucNumEntries; i++) — the raw firmware count, not the allocation count.

=> For ucNumEntries >= 9 on the pioneer SKU the loop writes (ucNumEntries - 8) * 28 bytes past the object. Worst case ucNumEntries = 255: allocation 228 bytes, writes through byte 7144, 6916 bytes past — a linear heap overflow repeating a 28-byte record whose first 4 bytes are an arbitrary VBIOS u32 (ulClk) and whose 5th byte is an arbitrary ucVddInd (only those two fields are written; the rest of each record keeps the kzalloc zeros, i.e. mostly-zero spray with a controlled dword every 28 bytes — classic heap-corruption primitive into the DragonFly kernel heap, kmalloc-backed kzalloc).

Trigger / threat model

Parse runs at vega10_pp_tables_initialize() (powerplay init, probe and every pp_table sysfs reload). Attacker controls the table bytes via: 1. a crafted/flashed VBIOS ROM image (supply chain / re-flashed card / passthrough ROM), or 2. root writing /sys/class/drm/card0/device/pp_table (amdgpu_pm.c:1007 DEVICE_ATTR pp_table S_IWUSR).

Device gate: PCI device id 0x6863, revision 0 ("pioneer" Vega10 SKU). The parse-side count itself is unconstrained on that SKU.

Reproduction (this pack)

Lifted-copy harness dcefclk_oflow.c (same approach the audit used for DF-1179 in the same driver family): the allocation decision and copy loop are replicated byte-for-byte with the real struct layouts (ATOM_Vega10_CLK_Dependency_Record = 8 bytes, phm_ppt_v1_clock_voltage_dependency_record = 28 bytes), the kzalloc is emulated by a canary-guarded calloc. Run on the audit guest (cc 8.3, DragonFly 6.5-DEVELOPMENT):

• ucNumEntries=6 → guard intact (workaround allocates 7, copy 6+1)
• ucNumEntries=9 → 28 bytes past the object (guard smashed)
• ucNumEntries=255 → writes through byte 7144 of the 228-byte object (6916 bytes past), first OOB record shows clk=0x3f0 (the VBIOS-chosen u32 landing in kernel heap memory)
• negative control A (device 0x687f) and B (revision 1): guards intact — proves the overflow is the pioneer-cap interaction, not the copy loop in general (non-pioneer paths alloc == copy count).
• PATCHED loop (fix.diff bound): guard intact with ucNumEntries=255.

The in-kernel path cannot run on the guest (no AMD GPU — run.log hardware gate), so this is a harness-level reproduction of the exact overflow arithmetic of the kernel code, per the project's DF-1179 precedent.

Fix

fix.diff (git apply --check OK): bound the copy loop by num_entries — identical to upstream's current code:

-   for (i = 0; i < clk_dep_table->ucNumEntries; i++) {
+   for (i = 0; i < num_entries; i++) {

Excess entries are dropped (same semantics upstream). The image-side count validation (reading 255 entries from an image that doesn't hold them) is covered by the DF-4396 central layer, whose unit test includes this path (dcefclk: pioneer fw=255 -> alloc 8, copy 8).

Fix validation: kernel-level not_testable (no ASIC on guest); harness patched-control proves the fixed bound stops the overflow; the DF-4396 patched parser (which subsumes this fix) syntax-validates with 0 errors on the guest kernel toolchain.

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.