• File: sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
• Lines: 1099–1107 (UVD), 1131–1139 (VCE), 1576–1587 (VCE state), 923–935 (v2 state walk)
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• CWE: CWE-125 Out-of-bounds Read
• Confidence: certain

Summary

In processpptables.c, AMDGPU PowerPlay table parsers index flexible-length arrays using UCHAR indices taken directly from VBIOS records and never compare those indices against the array's own length field. A crafted VBIOS drives the pointer arbitrarily far past the array — and ultimately past the mapped BIOS image — yielding OOB reads of kernel memory whose values are then copied into kzalloc'd hwmgr state and dereferenced as clock/voltage pointers.

Root cause

All of the indexed accesses trust the per-record UCHAR index with no bound check against the array's own count field:

• get_uvd_clock_voltage_limit_table, processpptables.c:1099-1107: &array->entries[table->entries[i].ucUVDClockInfoIndex] — array is a UVDClockInfoArray * with real length array->ucNumEntries (pptable.h:628-631), index never compared.
• get_vce_clock_voltage_limit_table, processpptables.c:1131-1139: &array->entries[table->entries[i].ucVCEClockInfoIndex] — same pattern; VCEClockInfoArray.ucNumEntries is the bound (pptable.h:582-585), never checked.
• get_vce_state_table_entry, processpptables.c:1576-1587: outer i is bounded only by the VBIOS-supplied numEntries, and the inner &vce_clock_info_array->entries[record->ucVCEClockInfoIndex] plus *clock_info = clock_arrays->clockInfo + clockInfoIndex*ucEntrySize where clockInfoIndex (= record->ucClockInfoIndex & 0x3F) is never checked against clock_arrays->ucNumEntries.
• pp_tables_get_entry (v2 path), processpptables.c:923-935: pstate_entry_v2->nonClockInfoIndex * pnon_clock_arrays->ucEntrySize and pstate_entry_v2->clockInfoIndex[i] * pclock_arrays->ucEntrySize — both UCHAR indices unbounded against the corresponding ucNumEntries.
• pp_tables_get_entry (legacy path), processpptables.c:944-957: same defect for ucNonClockStateIndex and ucClockStateIndices[i].

Enabler: get_powerplay_table (processpptables.c:827-849) stores hwmgr->soft_pp_table_size but it is never consulted anywhere in this file as a bound.

Threat

Local. Precondition: attacker controls the GPU VBIOS atom PowerPlay/FirmwareInfo tables. Two realistic placements:

1. Host root or physical access flashes a malicious VBIOS.
2. SR-IOV / virtualization where a malicious or compromised host feeds a guest's amdgpu driver a crafted atom BIOS image (smu_atom_get_data_table at smu_helper.c:660-673 returns bios + data_start straight from the per-device atom_context).

Impact: OOB read past the mapped BIOS region — panic if the next page is unmapped, otherwise attacker-influenced kernel bytes are dereferenced as clock/voltage pointers and later followed by hwmgr code, enabling controlled memory corruption. The VCE state entry path additionally hands the OOB-derived pointer back to the caller as *clock_info, broadening the deref surface.

Exploit / PoC

A PoC is a malicious VBIOS atom data table, not a userspace program (this surface has no syscall entry point). Steps:

1. Dump a reference PowerPlayInfo atom table from a target AMD GPU.
2. Forge a minimal PowerPlay table whose extended header (ATOM_PPLIB_EXTENDEDHEADER) advertises a VCE table offset; build the VCE table such that VCEClockInfoArray.ucNumEntries = 1 but every ATOM_PPLIB_VCE_Clock_Voltage_Limit_Record.ucVCEClockInfoIndex = 0xFF.
3. Write the modified BIOS into the GPU ROM (or, for SR-IOV, supply it to the guest atom context).
4. Bind amdgpu and observe the driver-load path: init_clock_voltage_dependency → get_vce_clock_voltage_limit_table reads array->entries[255] at processpptables.c:1132, landing 255*sizeof(VCEClockInfo) past a 1-entry array — typically outside the mapped BIOS region, producing an immediate kernel page-fault/panic (DoS proof) or, if the adjacent page is mapped, dereference of arbitrary kernel bytes as entry->ucEVClkHigh / usEVClkLow etc.

Recommended fix

Bounds-check every index against the corresponding array's ucNumEntries and validate the pointer stays within soft_pp_table_size. Pattern:

--- a/sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
@@ -1128,6 +1128,11 @@ static int get_vce_clock_voltage_limit_table(struct pp_hwmgr *hwmgr,
        return -ENOMEM;

    vce_table->count = table->numEntries;
+   if (array->ucNumEntries == 0)
+       return -EINVAL;
    for (i = 0; i < table->numEntries; i++) {
+       if (table->entries[i].ucVCEClockInfoIndex >= array->ucNumEntries)
+           return -EINVAL;
        const VCEClockInfo *entry = &array->entries[table->entries[i].ucVCEClockInfoIndex];

Apply the identical pattern to:

• get_uvd_clock_voltage_limit_table (processpptables.c:1099-1107)
• get_vce_state_table_entry (processpptables.c:1576-1587)
• pp_tables_get_entry v2 path (processpptables.c:923-935)
• pp_tables_get_entry legacy path (processpptables.c:944-957)

Related findings

• DF-1469 (sibling): inflated ucNumEntries count OOB in same file.
• DF-1470 (sibling): unvalidated VBIOS USHORT table offsets in same file.
• Part of the recurring "VBIOS offset/index OOB" family (radeon_atombios, radeon_combios, amdgpu_atombios, bios_parser, bios_parser2, intel_bios).