DF-4544 — vega20 OD count clamps are one-sided: VBIOS-sized allocations vs driver-enum indices

Severity: Medium (heap OOB read + filtered heap info leak via sysfs) | Confidence: certain File: sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c:823-846

What

init_powerplay_table_information() clamps the VBIOS-provided OverDrive8Table.ODFeatureCount / ODSettingCount from above only (lines 823-833):

od_feature_count = (le32_to_cpu(...ODFeatureCount) >
            ATOM_VEGA20_ODFEATURE_COUNT) ? ATOM_VEGA20_ODFEATURE_COUNT : ...;
od_setting_count = (le32_to_cpu(...ODSettingCount) >
            ATOM_VEGA20_ODSETTING_COUNT) ? ATOM_VEGA20_ODSETTING_COUNT : ...;

and then sizes the heap copies by those counts (copy_overdrive_feature_capabilities_array :694-695, phm_copy_overdrive_settings_limits_array smu_helper.c:73-74). A table that declares ODSettingCount = 1 therefore gets 4-byte od_settings_max / od_settings_min allocations and a 1-byte od_feature_capabilities allocation (ODFeatureCount = 1).

But the consumers in vega20_hwmgr.c index those arrays with the fixed driver-side enums, unconditionally, at driver init:

• vega20_od8_set_feature_capabilities reads od_settings_max/min[OD8_SETTING_*] for indices 1..13 (vega20_hwmgr.c:906-976; OD8_SETTING_ID vega20_hwmgr.h:398-417) and od_feature_capabilities[1..9] (:913-975)
• the fill loop (vega20_hwmgr.c:1216-1227) copies od_settings_min/max[i] into od8_settings_array[i].min/max
• vega20_print_clock_levels(OD_RANGE) (vega20_hwmgr.c:2861-2905) prints those values to the world-readable pp_od_clk_voltage sysfs node.

With ODSettingCount = 1 the first OOB read is od_settings_max[OD8_SETTING_GFXCLK_FMAX = 1] (vega20_hwmgr.c:907) — bytes 4..7 past a 4-byte kmalloc object; the farthest consumer index (13) reads at +52 B. A crafted VBIOS (or malicious vGPU ROM) therefore gets a heap out-of-bounds read window of up to ~52 bytes past a small kernel heap object, with the leaked u32s filtered only by the OD range gates and then exposed to unprivileged userspace through the OD_RANGE sysfs dump. Distinct from the knowns: DF-1689/DF-1690 are OOB reads of the VBIOS blob itself (no size validation); this finding is about the driver-side heap copies being sized by firmware counts that the clamps only bound from above.

Reproduce (lifted-copy harness, DF-1179/DF-4395 convention)

The in-kernel path needs a Vega20 ASIC with a crafted VBIOS (env.txt shows the guest has only the QEMU std VGA — no AMD GPU), so the harness replicates the exact struct layouts (vega20_pptable.h, pack(1)), the exact clamp logic, the kmalloc-sized arrays with a marker-filled "adjacent slab" tail, and the exact consumer condition sequence.

./build.sh     # cc -O2 -Wall (guest cc 8.3)
./run.sh

Expected (run.log): - CONTROL full counts (10/14) → 0 OOB reads, normal OD_RANGE output - CRAFTED ODFeatureCount=10 / ODSettingCount=1 → od_settings_max 4-byte object: 21 OOB reads, farthest +48 B past; od_settings_min 16 OOB reads; OD_RANGE prints SCLK: 800Mhz 2779054081Mhz — 2779054081 = 0xA5A50001, the marker planted at the first u32 past the object → heap leak to sysfs demonstrated - CRAFTED ODFeatureCount=1 → od_feature_capabilities 1-byte object: 9 OOB reads (indices 1..9) - PATCHED (fix.diff: allocations floored at the driver counts) → same crafted input, 0 OOB reads, no markers in the output

Fix validation

• fix.diff — git apply --check OK; allocations floored at ATOM_VEGA20_ODFEATURE_COUNT / ATOM_VEGA20_ODSETTING_COUNT, copies bounded
• full amdgpu.ko module rebuilt with the patch applied under the real kernel toolchain (-Werror): RC=0 (fix_build.log); guest /usr/src restored to pristine afterwards
• harness PATCHED control: 0 OOB reads for the same crafted input

Files

• od_count_oflow.c — the harness (sha256 a55b58d859d8addc4358bea67a58bcba7faff0150d0f38c999bf4a2c3854f1a2)
• build.sh / run.sh, build.log / run.log / run.2.log / fix_run.log
• fix.diff, fix_build.log, env.txt, VERDICT.md, manifest.json, verdict.json

VERDICT — DF-4544

Reproduced: YES (lifted-copy harness on the audit guest; in-kernel path hardware-gated)

• Root cause proven (vega20_processpptables.c:823-846): the clamps min(VBIOS_count, ATOM_VEGA20_ODSETTING_COUNT) are one-sided — they only bound the count from above. The kzalloc calls (copy_overdrive_feature_capabilities_array :695, phm_copy_overdrive_settings_limits_array smu_helper.c:73-75) size the heap arrays by exactly that clamped count.
• Consumer indices proven (vega20_hwmgr.c): vega20_od8_set_feature_ capabilities (:906-976) indexes od_settings_max/min at OD8_SETTING_GFXCLK_FMAX=1 first (line 907) and up to index 13; the fill loop (:1216-1227) writes od_settings_min/max[i] into od8_settings_array[i]; print_clock_levels(OD_RANGE) (:2861-2905) prints min/max to the world-readable OD sysfs node. Driver enum has 16 members (vega20_hwmgr.h:398-417); the fill loop guards i via feature_id which is only ever set for 0..13 — hence indices 0..13 vs an allocation that can legally be a single u32.
• Harness result (run.log, deterministic, 3 runs incl. run.2.log): crafted ODFeatureCount=10/ODSettingCount=1 → od_settings_max = 4-byte object, 21 OOB reads, farthest +48 B past; od_settings_min 16 OOB reads; od_feature OOB (idx 1..9) with ODFeatureCount=1 → 9 reads past a 1-byte object. The u32 at the first OOB slot (0xA5A50001 = 2779054081) passed the OD gates and was printed as SCLK: 800Mhz 2779054081Mhz in the replicated OD_RANGE output — the sysfs exfil path is real, gated only by comparisons the attacker's heap contents must satisfy (> 0, >= min, <= 100 for the power-percentage setting). In the kernel the values read are whatever follows the small kmalloc object in its slab.
• Controls: full-count table → 0 OOB reads; PATCHED (floors) → 0 OOB reads, no markers printed.

Why not uid=0

Information-disclosure class, not corruption: the primitive is a bounded (few dozen bytes) read window past a small heap object, filtered through range gates, at driver-load time (one-shot — the arrays are parsed once at pptable_init). No write primitive, no repeat trigger without a driver reload. Realistic ceiling: opportunistic heap-content disclosure to an unprivileged sysfs reader on a machine whose VBIOS/ROM was crafted. Threat model requires attacker-controlled firmware (physical flash / vGPU+custom ROM), same precondition as the known DF-1689/DF-1690 family.

Fix validation

• git apply --check OK (generated against pristine sys/; never applied there)
• Full amdgpu.ko rebuild with the fix under the real kernel toolchain with -Werror: RC=0 (fix_build.log); /usr/src restored + verified
• Harness PATCHED control: 0 OOB reads for the same crafted input

Kernel refs

sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c:823, sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c:829, sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c:835, sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c:839, sys/dev/drm/amd/powerplay/hwmgr/smu_helper.c:73, sys/dev/drm/amd/powerplay/hwmgr/vega20_hwmgr.h:398, sys/dev/drm/amd/powerplay/hwmgr/vega20_hwmgr.c:906, sys/dev/drm/amd/powerplay/hwmgr/vega20_hwmgr.c:1216, sys/dev/drm/amd/powerplay/hwmgr/vega20_hwmgr.c:2861, sys/dev/drm/amd/powerplay/hwmgr/vega20_pptable.h:76

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.