DF-1254 PoC — vega20 OD8 OOB read (LATENT)

Status: source-confirmed real; NOT reproducible on audit guest (no AMD GPU). Impact: heap OOB read (info leak) via crafted VBIOS powerplay table. Driver: sys/dev/drm/amd/powerplay/hwmgr/vega20_hwmgr.c + vega20_processpptables.c (amdgpu, not in GENERIC, no HW).

Reproduce

./build.sh && ./run.sh   # trigger is a stub; bug path is VBIOS-parse/GPU-init

The bug fires only at Vega20 GPU powerplay init with a crafted VBIOS. See VERDICT.md for the full source-level trace and fix.diff for the fix.

DF-1254 — vega20 OD8 capability/settings arrays: heap OOB read (LATENT)

Verdict

NOT REPRODUCED on the audit guest (LATENT / HW-gated). The bug is confirmed real by source-level trace; it cannot fire on this guest because there is no AMD GPU, so the dev/drm/amd powerplay/VBIOS-parse path is dead code at runtime.

Mechanism (confirmed in source)

• vega20_processpptables.c:824-846 computes od_feature_count = min(VBIOS.ODFeatureCount, ATOM_VEGA20_ODFEATURE_COUNT) (10) and od_setting_count = min(VBIOS.ODSettingCount, ATOM_VEGA20_ODSETTING_COUNT) (14).
• copy_overdrive_feature_capabilities_array (vega20_processpptables.c:694) allocates exactly od_feature_count bytes (kzalloc(count)), and phm_copy_overdrive_settings_limits_array (smu_helper.c:73) allocates exactly od_setting_count u32s. So a VBIOS reporting ODFeatureCount<10 or ODSettingCount<14 yields an undersized destination buffer.
• The consumer vega20_od8_set_feature_capabilities (vega20_hwmgr.c:906-975) indexes od_feature_capabilities[ATOM_VEGA20_ODFEATURE_*] with the hardcoded constants 0..9, and vega20_od8_initialize_default_settings (vega20_hwmgr.c:1216-1221) indexes od_settings_min/max[i] for i in 0..OD8_SETTING_COUNT. These constant indices exceed the undersized allocation → heap OOB read (kmalloc-16/32 bucket).
• check_powerplay_tables (vega20_processpptables.c:636) validates neither count. OOB values surface via pp_od_clk_voltage sysfs → heap info leak.
• VBIOS source arrays ODFeatureCapabilities[32], ODSettingsMax[32], ODSettingsMin[32] (vega20_pptable.h:80-83) are declared 32-wide, so the copy itself never over-reads; only the destination is too small.

Why it does not reproduce here

pciconf -lv shows no display/VGA device; the guest has display none. amdgpu.ko/drm.ko ship in /boot/kernel/ but are not loaded (no AMD GPU to probe), and even loaded they would not attach. The vulnerable code runs only during GPU powerplay init while parsing a real (or crafted) VBIOS. Reaching it needs a Vega20-class AMD GPU + a crafted powerplay table — neither available. This is a valid hard blocker: the code path is unreachable at runtime on this guest and no userspace syscall exercises it.

Exploit chain

N/A — read-only OOB (info leak), and HW-gated (latent). No escalation chain is developable on this guest. Realistic threat: a malicious/crafted VBIOS on real AMD hardware (reflashed card or hostile PCIe device) leaking heap bytes.

PoC changes

trigger.c is a documentation stub (the bug path is not a syscall); the real deliverables are this trace and fix.diff.

Fix (fix.diff)

Always allocate the full ATOM_VEGA20 maximum so the consumer's hardcoded indices cannot run off the end; copy only the VBIOS-declared valid entries (the rest stay zeroed from kzalloc). Concretely: - copy_overdrive_feature_capabilities_array: allocate ATOM_VEGA20_ODFEATURE_MAX_COUNT (32) instead of od_feature_count. - new vega20_copy_overdrive_settings_limits_array (vega20-local) allocates ATOM_VEGA20_ODSETTING_MAX_COUNT (32) and copies od_setting_count entries; the two vega20 call sites use it instead of the shared phm_copy_overdrive_settings_limits_array (which vega12 still uses with its own full constant count, unaffected). Applies cleanly (patch -p1 rc=0). Supersedes the finding markdown proposal (which had no markdown; this is the authoritative verified fix).

Fix validation

not_testable — the code path is not reachable on the audit guest, so no PoC runs before/after. Validated: diff applies cleanly to the read-only sys/ tree and is syntactically reviewed; building the amdgpu/powerplay stack is not warranted for a non-reproducible latent OOB read.