Summary

check_powerplay_tables() only asserts sHeader.structuresize > 0 and never validates that the VBIOS-reported size covers the full ATOM_Vega20_POWERPLAYTABLE layout (including the multi-KB inline PPTable_t smcPPTable).

The parser then unconditionally dereferences fields far past the reported size — most importantly memcpy-ing sizeof(PPTable_t) bytes from &powerplay_table->smcPPTable at line 884. A malicious/corrupted VBIOS that positions the powerplayinfo data table near the end of the BIOS heap allocation (or simply reports a small structuresize) causes the parser to read past the end of adev->bios (allocated via kmalloc in amdgpu_bios.c).

This is the same defect class as the sibling parsers DF-1468 (processpptables.c), DF-1574 (process_pptables_v1_0.c), and DF-1586 (vega10_processpptables.c); vega20 confirms the pattern persists.

Root cause

get_powerplay_table() (lines 44-62) calls smu_atom_get_data_table() which returns (uint8_t *)atom_context->bios + data_start (smu_helper.c:669-670) where data_start is a 16-bit offset pulled verbatim from the VBIOS data_table by amdgpu_atom_parse_data_header (atom.c:1384-1403) with NO validation against bios_size. The reported size is stored into hwmgr->soft_pp_table_size but never compared to sizeof(ATOM_Vega20_POWERPLAYTABLE).

check_powerplay_tables() (lines 636-657) only checks:

• format_revision >= 11
• structuresize > 0
• smcPPTable.Version == PPTABLE_V20_SMU_VERSION

— all of which can be satisfied by a 16-byte table.

init_powerplay_table_information() then reads fields at fixed offsets throughout the entire ATOM_Vega20_POWERPLAYTABLE layout: hwmgr->thermal_controller.fanInfo.ulMaxRPM = powerplay_table->smcPPTable.FanMaximumRpm (line 815), the OverDrive8Table.ODSettingsMax[] access (line 857), and crucially the memcpy(pptable_information->smc_pptable, &(powerplay_table->smcPPTable), sizeof(PPTable_t)) at lines 884-886 which copies a multi-KB inline structure whose offset+size routinely exceeds any small structuresize.

Since ATOM_Vega20_POWERPLAYTABLE embeds PPTable_t smcPPTable inline (vega20_pptable.h:136) rather than via an offset, the parser cannot avoid reading the full structure footprint regardless of the VBIOS-reported size.

Threat model

Attacker position: anyone who controls the GPU's VBIOS image — a malicious card in the supply chain, a re-flashed EEPROM (some cards expose VBIOS flash via userspace tools / MMIO), or a virtualization setup passing through a crafted PCI option ROM.

Precondition: amdgpu driver loads and calls vega20_pp_tables_initialize() (line 894) via vega20_hwmgr_init path.

Impact:

1. kernel heap OOB read past the adev->bios kmalloc allocation when data_start + sizeof(ATOM_Vega20_POWERPLAYTABLE) exceeds bios_size; the memcpy at line 884 is the cleanest OOB primitive since it copies a known large size
2. The OOB-read bytes (adjacent kernel heap contents) are then exposed to userspace indirectly via sysfs attributes derived from pptable_information (clock limits, OD limits, TDPODLimit at line 857) and are also sent to the SMU microcontroller as configuration, which can cause GPU hardware misbehavior (over-volt/over-clock)

No direct path to kernel code execution was demonstrated from this file alone — impact is bounded info leak of adjacent heap + hardware-config corruption.

PoC

PoC is a VBIOS image patch, not a userspace program, because the attack surface is firmware-supplied data consumed at driver init. Steps:

1. Obtain a Vega20 VBIOS image (e.g. dump from a Radeon VII / MI50 via amdgpu.gpu_recovery=0 + MMIO strap, or extract the PCI option ROM with pci-tools).
2. Locate the ATOM master data_table; find the index for powerplayinfo (via GetIndexIntoMasterDataTable(powerplayinfo) — same lookup the driver uses at line 46).
3. Patch that data table entry's data_start to a 16-bit value near bios_size (e.g. bios_size - 32), OR set the structuresize field at the data_start offset to 1, while keeping format_revision=11 (ATOM_VEGA20_TABLE_REVISION_VEGA20), content_revision to pass, and the byte at smcPPTable.Version offset = PPTABLE_V20_SMU_VERSION (so check_powerplay_tables lines 640-652 still pass).
4. Reprogram the SPI EEPROM with the modified image, OR feed it to a VM via pci-passthrough of an emulated option ROM.
5. Trigger driver (re-)bind: echo > /sys/bus/pci/drivers/amdgpu/bind or boot.

Expected outcome: amdgpu calls vega20_pp_tables_initialize → init_powerplay_table_information → the memcpy at line 884 reads sizeof(PPTable_t) (~2 KB) bytes starting near the end of the BIOS allocation, going past bios_size into adjacent kernel heap.

A KASAN-enabled kernel reports a slab-out-of-bounds read; on a production kernel the read silently returns adjacent heap bytes that then appear in sysfs (e.g. /sys/class/drm/card0/device/... pp_dpm_sclk / OD settings) and are pushed to the SMU.

findings/poc/DF-1689/: drop the patched VBIOS as vega20_poisoned_vbios.bin plus a Python script patch_vbios.py that takes a stock Vega20 VBIOS dump and writes the patched image with the data_start/structuresize fields set as described; include the binding trigger script trigger.sh.

Recommended fix

Validate that the VBIOS-reported size actually covers the full ATOM_Vega20_POWERPLAYTABLE structure before any field is read, and additionally guard against data_start running past bios_size.

Minimal in-file fix:

--- a/sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/vega20_processpptables.c
@@ -636,11 +636,18 @@ static int check_powerplay_tables(
        struct pp_hwmgr *hwmgr,
        const ATOM_Vega20_POWERPLAYTABLE *powerplay_table)
 {
+   u16 struct_size = le16_to_cpu(powerplay_table->sHeader.structuresize);
+
    PP_ASSERT_WITH_CODE((powerplay_table->sHeader.format_revision >=
        ATOM_VEGA20_TABLE_REVISION_VEGA20),
        "Unsupported PPTable format!", return -1);
    PP_ASSERT_WITH_CODE(powerplay_table->sHeader.structuresize > 0,
        "Invalid PowerPlay Table!", return -1);
+   PP_ASSERT_WITH_CODE(struct_size >= sizeof(ATOM_Vega20_POWERPLAYTABLE),
+       "PowerPlay Table size too small for vega20 layout!",
+       return -EINVAL);
+   PP_ASSERT_WITH_CODE(hwmgr->soft_pp_table_size == 0 ||
+           hwmgr->soft_pp_table_size >= sizeof(ATOM_Vega20_POWERPLAYTABLE),
+       "PowerPlay Table allocation too small!", return -EINVAL);

    if (powerplay_table->smcPPTable.Version != PPTABLE_V20_SMU_VERSION) {
        pr_info("Unmatch PPTable version: "

Defense-in-depth: amdgpu_atom_parse_data_header() in sys/dev/drm/amd/amdgpu/atom.c:1384 should also reject data_start values where data_start + size > ctx->bios_size, but that fix belongs to atom.c, not this file.

Related findings

VBIOS PowerPlay parser count/offset family:

• DF-1468 (processpptables.c)
• DF-1574 (process_pptables_v1_0.c)
• DF-1586 (vega10_processpptables.c)
• DF-1560 (amd_powerplay.c)
• DF-1674 (amdgpu_dpm.c)

Related sibling

• DF-1690 (smc_dpm_info table — same file, separate OOB)