• File: sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
• Lines: 1498, 1499, 1500, 1502, 1504, 1506, 1515, 1516, 1518, 1520, 1522
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U:C:L/I:L/A:H
• CWE: CWE-125 Out-of-bounds Read
• Confidence: likely

Summary

atomctrl_get_leakage_vddc_base_on_leakage() derives four sub-buffers inside the ASIC_ProfilingInfo V2_1 table by adding attacker-controlled USHORT offsets (usLeakageBinArrayOffset, usElbVDDC_IdArrayOffset, usElbVDDC_LevelArrayOffset, and the VDDCI analogues) to the table base, then indexes them with UCHAR counts (ucLeakageBinNum, ucElbVDDC_Num, ucElbVDDCI_Num) that are never compared to anything.

The 2-D index vddc_buf[j*ucElbVDDC_Num + i] can reach ~65K u16s past the offset, reading arbitrarily far through kernel-mapped VBIOS memory; the resulting garbage is returned as a VDDC/VDDCI voltage level.

Root cause

ppatomctrl.c:1495-1497 only verifies usStructureSize >= sizeof(ATOM_ASIC_PROFILING_INFO_V2_1) — it never validates that the four USHORT offsets (usLeakageBinArrayOffset etc., atombios.h:5255-5268) plus the corresponding array extents fall inside usStructureSize.

ppatomctrl.c:1498-1500 computes leakage_bin/vddc_id_buf/vddc_buf = (u16*)((char*)profile + <USHORT offset>) — a USHORT offset (max 65535) added to the table base can land anywhere within (or past) the mapped BIOS image.

ppatomctrl.c:1501-1512 then loops for (i=0;i<profile->ucElbVDDC_Num;i++) reading vddc_id_buf[i] and, inside, for (j=0;j<profile->ucLeakageBinNum;j++) reads leakage_bin[j] and vddc_buf[j*profile->ucElbVDDC_Num + i].

With UCHAR maxima, j*ucElbVDDC_Num+i can be 254*255+254 = 65279, i.e. vddc_buf[65279] reads 130 KB past the chosen offset.

The header-size check at :1497 gives no protection against this because the counts/offsets are independent VBIOS fields.

The VDDCI block at ppatomctrl.c:1515-1529 repeats the identical defect.

Threat

Local, kernel-context, reached via the powerplay leakage-table init path that calls atomctrl_get_leakage_vddc_base_on_leakage.

Precondition: attacker controls the ASIC_ProfilingInfo V2_1 atom table (forged VBIOS flash or SR-IOV/VFIO guest injection — same model as DF-1468 and DF-1496).

Impact:

• (a) OOB read of the mapped BIOS region — if the OOB index crosses into an unmapped page the kernel page-faults and panics (A:H DoS);
• (b) if adjacent memory is mapped, attacker-influenced kernel bytes are returned as the *vddc/*vddci voltage level and later programmed toward GPU voltage rails, which can drive the part out of spec (I:L hardware-stress).

The C:L reflects that a small, noisy leak of adjacent BIOS/kernel bytes is possible on configs where the BIOS image is neighbored by other kernel data.

Same vulnerability class as DF-1468 (processpptables.c) and DF-1470, just in the profiling-info parser.

Exploit / PoC

Forge an ASIC_ProfilingInfo atom table (DATA, ASIC_ProfilingInfo) with ucTableFormatRevision=2, ucTableContentRevision>=1, usStructureSize=sizeof(ATOM_ASIC_PROFILING_INFO_V2_1) (passes the :1497 gate), then set ucElbVDDC_Num=0xFF, ucLeakageBinNum=0xFF, usElbVDDC_LevelArrayOffset=0xFFFF, usLeakageBinArrayOffset=0xFFFF, usElbVDDC_IdArrayOffset pointing to a valid virtual_voltage_id match.

Flash/inject and trigger leakage init: ppatomctrl.c:1506 computes vddc_buf[254*255+i], reading ~130 KB past the table.

Success criteria: either

• (a) kernel page-fault panic if the read crosses an unmapped page after the BIOS image (clean DoS proof), or
• (b) capture the returned *vddc on a config where the bytes are mapped, demonstrating attacker-influenced voltage selection.

Recommended fix

Validate each USHORT offset and each UCHAR count against usStructureSize before indexing, capping the 2-D product. Minimal bound check pattern:

--- a/sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c
@@ -1495,6 +1495,14 @@ int atomctrl_get_leakage_vddc_base_on_leakage(struct pp_hwmgr *hwmgr,
    if ((profile->asHeader.ucTableFormatRevision >= 2) &&
        (profile->asHeader.ucTableContentRevision >= 1) &&
        (profile->asHeader.usStructureSize >= sizeof(ATOM_ASIC_PROFILING_INFO_V2_1))) {
+       unsigned int tbl_sz = le16_to_cpu(profile->asHeader.usStructureSize);
+       u8 *base = (u8 *)profile;
+#define LEAK_OFFSET_OK(off, cnt) \
+       ((le16_to_cpu(off) <= tbl_sz) && \
+        ((unsigned long)le16_to_cpu(off) + (unsigned long)(cnt) * sizeof(u16) <= tbl_sz))
+       if (!LEAK_OFFSET_OK(profile->usElbVDDC_IdArrayOffset, profile->ucElbVDDC_Num) ||
+           !LEAK_OFFSET_OK(profile->usElbVDDC_LevelArrayOffset,
+                   (profile->ucElbVDDC_Num * profile->ucLeakageBinNum)))
+           return -EINVAL;
        leakage_bin = (u16 *)((char *)profile + profile->usLeakageBinArrayOffset);
        vddc_id_buf = (u16 *)((char *)profile + profile->usElbVDDC_IdArrayOffset);

Apply the same LEAK_OFFSET_OK guard to the VDDCI block at ppatomctrl.c:1515-1522 and to leakage_bin (usLeakageBinArrayOffset / ucLeakageBinNum).

Note: ATOM_ASIC_PROFILING_INFO_V2_1 offset fields are stored little-endian on disk; the helper already uses le16_to_cpu, and the existing dereferences at :1498-1500 should be converted to le16_to_cpu(profile->usXxxOffset) for correctness on big-endian hosts as part of the same fix.

Related findings

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