Summary

append_vbios_pptable() retrieves a second VBIOS data table (smc_dpm_info) via smu_atom_get_data_table() passing NULL for the size out-parameter, then dereferences fields throughout struct atom_smc_dpm_info_v4_4 (including a 7-element i2ccontrollers[] loop) without confirming the underlying VBIOS allocation actually contains the full structure.

A malicious VBIOS that supplies a short smc_dpm_info table — or positions it near the end of the BIOS heap allocation — drives every field read in this function past the end of adev->bios, leaking adjacent kernel heap bytes into PPTable_t fields that are subsequently pushed to the SMU and partly exposed via sysfs.

Root cause

Line 721:

smc_dpm_table = smu_atom_get_data_table(hwmgr->adev, index, NULL, NULL, NULL);

— the third argument is NULL, so the table's actual byte size is discarded.

smu_atom_get_data_table() (smu_helper.c:660-673) returns bios + data_start where data_start is a 16-bit VBIOS-controlled offset that amdgpu_atom_parse_data_header() (atom.c:1384-1403) does NOT bounds-check against bios_size.

The only guard is the PP_ASSERT_WITH_CODE at lines 720-723 which checks the pointer is non-NULL but says nothing about size. The function then reads smc_dpm_table->maxvoltagestepgfx (line 725), smc_dpm_table->vddgfxvrmapping (728), ... smc_dpm_table->acdcgpio (753), smc_dpm_table->ledpin0 (763), smc_dpm_table->pllgfxclkspreadenabled (767), smc_dpm_table->fllgfxclkspreadfreq (781), and the i2ccontrollers[0..6] loop at 783-796 — every access assumes the full sizeof(struct atom_smc_dpm_info_v4_4) is present.

Threat model

Attacker position: same as DF-1689 — controls the GPU VBIOS image.

Precondition: amdgpu driver init reaches init_powerplay_table_information() which calls append_vbios_pptable() at line 889; this happens unconditionally on every Vega20 card load (no flag gating).

Impact: OOB read of bytes adjacent to the BIOS kmalloc when VBIOS supplies an smc_dpm_info data table whose data_start is near bios_size or whose recorded size is smaller than sizeof(struct atom_smc_dpm_info_v4_4). The OOB-read values are then written into the in-kernel PPTable_t copy and later transmitted to the SMU via SMU message tables; some are reflected to userspace through powerplay sysfs attributes (voltage mapping, spread-spectrum percentages, fan GPIO info).

No direct RCE path demonstrated; impact is heap info leak + attacker-influenced hardware configuration.

PoC

Same VBIOS-patch workflow as DF-1689, but target the smc_dpm_info entry instead of powerplayinfo:

1. Dump a Vega20 VBIOS image.
2. In the ATOM master data_table, find the index returned by GetIndexIntoMasterDataTable(smc_dpm_info) (the same index the driver uses at line 717).
3. Patch that entry's data_start to bios_size - 16 (small offset near the end), keeping the master data_table entry non-zero so amdgpu_atom_parse_data_header returns true.
4. Reprogram SPI EEPROM or feed via VM pci-passthrough.
5. Bind amdgpu driver.

The driver calls append_vbios_pptable → smc_dpm_table is non-NULL (passes the only guard at lines 720-723) → field reads at smc_dpm_table->maxvoltagestepgfx ... i2ccontrollers[6] all read past the BIOS allocation.

KASAN-enabled kernel reports a slab-out-of-bounds read at the first field access past the BIOS tail; production kernel silently leaks adjacent heap bytes into the SMU config.

findings/poc/DF-1690/: drop the patcher as patch_smc_dpm.py alongside the primary PoC.

Recommended fix

Pass a non-NULL size out-parameter to smu_atom_get_data_table() and reject tables smaller than the structure footprint before any field access.

--- a/sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c
@@ -714,9 +714,11 @@
 static int append_vbios_pptable(struct pp_hwmgr *hwmgr, PPTable_t *ppsmc_pptable)
 {
    struct atom_smc_dpm_info_v4_4 *smc_dpm_table;
+   u16 size;
    int index = GetIndexIntoMasterDataTable(smc_dpm_info);
    int i;

    PP_ASSERT_WITH_CODE(
-       smc_dpm_table = smu_atom_get_data_table(hwmgr->adev, index, NULL, NULL, NULL),
+       smc_dpm_table = smu_atom_get_data_table(hwmgr->adev, index, &size, NULL, NULL),
        "[appendVbiosPPTable] Failed to retrieve Smc Dpm Table from VBIOS!",
        return -1);
+   PP_ASSERT_WITH_CODE(size >= sizeof(*smc_dpm_table),
+       "[appendVbiosPPTable] Smc Dpm Table too small!", return -EINVAL);

    ppsmc_pptable->MaxVoltageStepGfx = smc_dpm_table->maxvoltagestepgfx;

Note: le16_to_cpu is not needed on size because smu_atom_get_data_table() already stores the value via *size = CU16(idx) (atom.c:1395-1396) without endian conversion of the out-param; if a future change makes the helper endian-pure, add le16_to_cpu(size) here.

Related findings

VBIOS PowerPlay parser count/offset family:

• DF-1689 (sibling: powerplayinfo table OOB in same file)
• DF-1468/1574/1586 (other VBIOS PowerPlay parsers)