• File: sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
• Lines: 383–399 (clock_voltage_dep), 1089–1107 (uvd), 1122–1139 (vce), 1153–1167 (samu), 1181–1195 (acp), 1379–1399 (cac_leakage), 1520–1537 (phase_shed)
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• CWE: CWE-129 Improper Validation of Array Index
• Confidence: certain

Summary

Every table parser in processpptables.c allocates a destination buffer sized by a VBIOS-supplied UCHAR count (ucNumEntries / numEntries) and then iterates that many times reading table->entries[i] from the source VBIOS region. Neither the count nor the implied byte range is ever checked against the size of the source firmware image (hwmgr->soft_pp_table_size, which itself comes from the VBIOS atom header at processpptables.c:844). A crafted VBIOS that advertises e.g. ucNumEntries=255 for a table that physically contains 2 entries causes the loop to read 253 records' worth of memory past the end of the table — out of the mapped BIOS region and into adjacent kernel memory.

Root cause

Recurring defect: count taken directly from VBIOS, used as both the allocation multiplier and the loop bound, never validated to fit inside the image. Concrete sites:

• get_clock_voltage_dependency_table, processpptables.c:383-399: table_size = sizeof(unsigned long) + sizeof(struct phm_clock_voltage_dependency_table) * table->ucNumEntries; then for (i = 0; i < dep_table->count; i++) dep_table->entries[i].clk = ... le16_to_cpu(table->entries[i].usClockLow); — table->entries[i] runs past the source table when ucNumEntries is inflated.
• get_uvd_clock_voltage_limit_table, processpptables.c:1089-1107: table->numEntries controls both kzalloc size and the loop reading table->entries[i].
• get_vce_clock_voltage_limit_table, processpptables.c:1122-1139: same with table->numEntries.
• get_samu_clock_voltage_limit_table, processpptables.c:1153-1167: same.
• get_acp_clock_voltage_limit_table, processpptables.c:1181-1195: same.
• get_cac_leakage_table, processpptables.c:1379-1399: same with table->ucNumEntries.
• init_phase_shedding_table, processpptables.c:1520-1537: same with ptable->ucNumEntries.
• pp_tables_get_num_of_entries, processpptables.c:874-880: hands ucNumEntries (or ucNumStates) straight back to the caller, which then loops in smu7_hwmgr.c:3372 / smu8_hwmgr.c:1388 / smu10_hwmgr.c:777 calling pp_tables_get_entry that many times; an inflated count drives every subsequent state-table walk out of bounds (compounds DF-1468).

In every case hwmgr->soft_pp_table_size (set at processpptables.c:844) is available but unused as a bound.

Threat

Same local attacker position as DF-1468 (malicious VBIOS or SR-IOV guest). Inflating ucNumEntries to 255 for a small table causes 253*sizeof(record) of OOB read from the mapped BIOS region; the read values become clk/v/vclk/vddc fields copied into freshly kzalloc'd hwmgr state and later consumed by clock/voltage programming.

If the OOB read crosses into an unmapped page the kernel panics (DoS); if it crosses into other kernel memory, those bytes are parsed as clocks/voltages and may drive MMIO writes (controlled corruption primitive). Because get_clock_voltage_dependency_table output is later exposed to userland via sysfs (clocks read back through amdgpu_hwmon / pp_dpm_sclk etc.), the OOB-read bytes can also leak to userspace.

Exploit / PoC

Forge a PowerPlay table whose ATOM_PPLIB_Clock_Voltage_Dependency_Table (reachable from ATOM_PPLIB_POWERPLAYTABLE4.usVddcDependencyOnSCLKOffset, processpptables.c:1304-1310) declares ucNumEntries = 255 while the table physically contains one record. Build the atom BIOS image with this table, load via VBIOS flash or SR-IOV guest atom context, and trigger init_clock_voltage_dependency at driver attach. get_clock_voltage_dependency_table allocates 255 entries worth of memory and then loops i=0..254 reading table->entries[i].usClockLow / usVoltage from progressively OOB addresses (processpptables.c:393-398).

Observable on a stock DFBSD/amdgpu guest is either a panic in get_clock_voltage_dependency_table (if BIOS mapping ends nearby) or, with the table placed mid-image, silent ingestion of garbage clock/voltage pairs that surface via cat /sys/class/drm/card0/device/powerplay/hwmon/hwmon?/freq*_input and /sys/.../pp_dpm_sclk (info leak).

Recommended fix

Add a helper that bounds any (offset, count, record_size) triple inside hwmgr->soft_pp_table_size, and call it before every count-driven loop:

--- a/sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
@@ -375,6 +375,15 @@ static int get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr,
        const ATOM_PPLIB_Clock_Voltage_Dependency_Table *table)
 {

+   /*
+    * The caller resolved `table` from a VBIOS offset; make sure the
+    * declared entry count actually fits in the firmware image.
+    */
+   if ((unsigned long)((const uint8_t *)table - (const uint8_t *)hwmgr->soft_pp_table)
+       + sizeof(*table) + (unsigned long)table->ucNumEntries *
+         sizeof(table->entries[0]) > hwmgr->soft_pp_table_size)
+       return -EINVAL;
+
    unsigned long table_size, i;

Apply the same precondition to get_uvd_clock_voltage_limit_table (1089), get_vce_clock_voltage_limit_table (1122), get_samu_clock_voltage_limit_table (1153), get_acp_clock_voltage_limit_table (1181), get_cac_leakage_table (1379), and init_phase_shedding_table (1520).

Related findings

• DF-1468 (sibling): unbounded per-record index into clock-info arrays.
• DF-1470 (sibling): unvalidated VBIOS USHORT table offsets.
• Part of the recurring "VBIOS power-table count overflow" family.