• File: sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
• Lines: 1368, 1374, 1375, 1383
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U:C:H/I:H/A:H
• CWE: CWE-787 Out-of-bounds Write
• Confidence: certain

Summary

atomctrl_get_smc_sclk_range_table() loops for (i=0; i<psmu_info->ucSclkEntryNum; i++) writing table->entry[i] where ucSclkEntryNum is a UCHAR taken straight from the VBIOS SMU_Info atom table with no comparison against the fixed array size (MAX_SCLK_RANGE=8).

Both the source (ATOM_SMU_INFO_V2_1.asSclkFcwRangeEntry[8], atombios.h:5640) and destination (pp_atom_ctrl_sclk_range_table.entry[8], ppatomctrl.h:244) are 8 entries; ucSclkEntryNum can be 0..255.

Both callers (polaris10_smumgr.c:803 and vegam_smumgr.c:673) allocate the destination as a 64-byte stack local, so ucSclkEntryNum>8 smashes up to ~2 KB of kernel stack.

psmu_info is also dereferenced without a NULL check.

Root cause

ppatomctrl.c:1368-1371 fetches psmu_info = smu_atom_get_data_table(...) which smu_helper.c:660-672 returns NULL when the SMU_Info data table header fails to parse. ppatomctrl.c:1374 then reads psmu_info->ucSclkEntryNum with no NULL guard (NULL deref → panic, a lesser DoS).

More seriously, the loop bound at :1374 is the raw VBIOS UCHAR ucSclkEntryNum and there is no PP_ASSERT_WITH_CODE((psmu_info->ucSclkEntryNum <= MAX_SCLK_RANGE), ...) anywhere — contrast atomctrl_get_voltage_table_v3:546-551 which DOES cap ucGpioEntryNum against PP_ATOMCTRL_MAX_VOLTAGE_ENTRIES.

Each iteration writes 5 fields (ucVco_setting, ucPostdiv, usFcw_pcc, usFcw_trans_upper, usRcw_trans_lower) into table->entry[i]; sizeof(pp_atom_ctrl_sclk_range_table_entry)=8 (ppatomctrl.h:234-240) and entry[] has MAX_SCLK_RANGE=8 slots (ppatomctrl.h:232,244) = 64 bytes total.

The two callers allocate struct pp_atom_ctrl_sclk_range_table range_table_from_vbios = {{{0}}}; on their stack frames (polaris10_smumgr.c:803 inside polaris10_get_sclk_range_table, vegam_smumgr.c:673 inside vegam_get_sclk_range_table) and pass &range_table_from_vbios as table.

With ucSclkEntryNum=255 the loop writes 255*8=2040 bytes starting at table->entry[0], i.e. ~1976 bytes past the end of the 64-byte stack object, overwriting saved frame pointer, return address, and adjacent frames.

This is the same defect class as DF-1468..DF-1472 (VBIOS-supplied count into a fixed kernel array) but uniquely yields a stack write rather than a read.

Threat

Local, kernel-context, reached on the amdgpu driver-load / powerplay-init path for CHIP_POLARIS10/11/12 (polaris10_smumgr) and VEGAM (vegam_smumgr).

Precondition: attacker controls the GPU VBIOS SMU_Info atom table. Two realistic placements matching the AGENT.md FS/VBIOS-image threat model:

1. Host root or an attacker with physical/PCI-bar access flashes a malicious VBIOS ROM;
2. SR-IOV / VFIO passthrough where a malicious or compromised host feeds a guest amdgpu driver a forged atom BIOS image — smu_atom_get_data_table (smu_helper.c:669) returns bios + data_start directly from the per-device atom_context, so the guest kernel consumes attacker bytes.

Impact: kernel stack buffer overflow during driver init. Without -fstack-protector on this build path it is a return-address overwrite → local kernel code execution; with stack canaries it is a reliable kernel panic (DoS) on every load.

The OOB read side (psmu_info->asSclkFcwRangeEntry[i] for i>=8) also leaks adjacent VBIOS/kernel bytes into the SMC DPM table that is later uploaded to the GPU.

Exploit / PoC

This surface has no syscall entry point; the PoC is a forged VBIOS atom data table, mirroring the DF-1468 family.

1. Dump a reference SMU_Info (DATA, SMU_Info) atom table from a Polaris10/ VEGAM target via atombios parsing.
2. Patch the ATOM_SMU_INFO_V2_1.ucSclkEntryNum byte (offset of ucSclkEntryNum within the struct = offsetof after the ATOM_COMMON_TABLE_HEADER) from its valid value (≤8) to 0xFF, leaving the 8 real asSclkFcwRangeEntry entries in place.
3. Recompute the atom master-data-table size/checksum so amdgpu_atom_parse_data_header accepts the forged image; write the image to the GPU ROM (host) or inject it into the guest atom_context (SR-IOV).
4. Bind amdgpu on a POLARIS10/POLARIS11/POLARIS12/VEGAM part; the load path polaris10_smumgr.c → polaris10_get_sclk_range_table:807 → atomctrl_get_smc_sclk_range_table:1374 runs unconditionally and writes table->entry[8..254].

Success = immediate kernel panic (stack smashing detected / page fault on stack guard) proving memory corruption; on a non-canary kernel build, replace the overflowed return-address bytes in the forged VBIOS image with a chosen value to redirect polaris10_get_sclk_range_table's return into kernel shellcode.

Recommended fix

Bounds-check ucSclkEntryNum against MAX_SCLK_RANGE and NULL-check psmu_info before the loop, matching the existing PP_ASSERT_WITH_CODE style used elsewhere in this file (e.g. :546-551).

--- a/sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
@@ -1365,11 +1365,19 @@ int atomctrl_get_smc_sclk_range_table(struct pp_hwmgr *hwmgr, struct pp_atom_ctr

    ATOM_SMU_INFO_V2_1 *psmu_info =
        (ATOM_SMU_INFO_V2_1 *)smu_atom_get_data_table(hwmgr->adev,
            GetIndexIntoMasterTable(DATA, SMU_Info),
            &size, &frev, &crev);

+   PP_ASSERT_WITH_CODE((NULL != psmu_info),
+           "Could not find SMU Info Table in BIOS.", return -EINVAL;);
+
+   PP_ASSERT_WITH_CODE((psmu_info->ucSclkEntryNum <= MAX_SCLK_RANGE),
+           "Too many SCLK range entries in SMU Info table!",
+           return -EINVAL;);
+
    for (i = 0; i < psmu_info->ucSclkEntryNum; i++) {
        table->entry[i].ucVco_setting = psmu_info->asSclkFcwRangeEntry[i].ucVco_setting;

Related findings

• DF-1468, DF-1469, DF-1470 (siblings, processpptables.c): same VBIOS-count-OOB class.
• DF-1497, DF-1498 (siblings): same file's other VBIOS-parser defects.