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

Summary

pp_dpm_set_pp_table() allocates hwmgr->hardcode_pp_table as a kmemdup of soft_pp_table of size hwmgr->soft_pp_table_size (a u16, typically 200–2000 bytes from the VBIOS ATOM PowerPlayInfo table), but then unconditionally memcpy()s the caller-supplied size bytes (the sysfs write count, up to PAGE_SIZE=4096 on x86_64) into that fixed-size buffer.

There is no check that size <= soft_pp_table_size.

The result is a fully attacker-controlled kernel heap overflow of up to ~3800 bytes into the adjacent kmalloc-* slab object.

Root cause

The vulnerable sequence in sys/dev/drm/amd/powerplay/amd_powerplay.c:676-711:

685:  if (!hwmgr->hardcode_pp_table) {
686:      hwmgr->hardcode_pp_table = kmemdup(hwmgr->soft_pp_table,
687:                                         hwmgr->soft_pp_table_size,
688:                                         GFP_KERNEL);
689:      if (!hwmgr->hardcode_pp_table)
690:          goto err;
691:  }
692:
693:  memcpy(hwmgr->hardcode_pp_table, buf, size);   /* <-- OVERFLOW */

hwmgr->soft_pp_table_size is a u16 sourced from smu_atom_get_data_table() — see sys/dev/drm/amd/powerplay/hwmgr/processpptables.c:838,844 and process_pptables_v1_0.c:147 — and reflects the size of the GPU's VBIOS PowerPlayInfo data table (a few hundred bytes for CZ/Tonga/Polaris, ~2–3 KiB for Vega10, ~4–8 KiB for Vega20).

The destination hardcode_pp_table is allocated to exactly that size via kmemdup() at line 686.

The source buf and length size come straight from the sysfs write path: amdgpu_set_pp_table() at sys/dev/drm/amd/amdgpu/amdgpu_pm.c:463-475 forwards (buf, count) unchanged via amdgpu_dpm_set_pp_table() (amdgpu_dpm.h:302-303) into pp_dpm_set_pp_table().

count is the vfs write count which the kernel caps at PAGE_SIZE per write.

No bound links size to soft_pp_table_size anywhere in the call chain, so any write larger than soft_pp_table_size corrupts memory past the end of the kmalloc-N slab object holding hardcode_pp_table.

The bug also persists across calls: on the second invocation hardcode_pp_table is already non-NULL (line 685 check), so the kmemdup is skipped and the original (small) buffer is reused, allowing the same overflow on every subsequent write.

Threat

Attacker position: any process with write access to /sys/class/drm/cardN/device/pp_table, which is mode 0644 (S_IRUGO|S_IWUSR — see amdgpu_pm.c:1007), i.e. uid 0 / CAP_SYS_ADMIN-equivalent on the box (or root inside a container/namespace that maps the host sysfs node, or any SELinux/AppArmor-confined root that is meant to be restricted from arbitrary kernel write).

Impact: arbitrary kernel heap corruption with full attacker control of both the bytes written and the overflow length (any value from 1 to ~4096 past the end of a known-size kmalloc allocation).

On a system running a vulnerable amdgpu driver on AMD graphics hardware, this is a reliable kernel-mode-code-execution / kernel-privilege-escalation primitive usable to escape sandboxing/securelevel restrictions or to bypass kernel hardening.

Reach requires AMD GPU attached and amdgpu loaded with DPM enabled (hwmgr->pm_en true, which is the default when amdgpu.dpm=1, the default for all Vi+ ASICs).

Exploit / PoC

# pp_table_overflow.py — as root on an amdgpu system
import os
path = '/sys/class/drm/card0/device/pp_table'
cur = open(path, 'rb').read()
print('current soft_pp_table size:', len(cur))
payload = b'A' * 4096
fd = os.open(path, os.O_WRONLY)
n = os.write(fd, payload)
print('wrote', n, 'bytes into a', len(cur), '-byte allocation')
os.close(fd)

On a typical CZ/Polaris board where soft_pp_table_size is, e.g., 197 or 1234 bytes, writing 4096 corrupts ~3000–3900 bytes of adjacent slab memory.

With KASAN enabled this panics immediately with BUG: KASAN: slab-out-of-bounds in pp_dpm_set_pp_table+0x....

Without KASAN, the next slab object's contents are silently corrupted; an exploitation chain would groom the slab so a victim object containing a function pointer sits immediately after hardcode_pp_table, trigger the overflow to set that pointer, then drive the victim to gain kernel-privileged control flow.

Recommended fix

Validate that the caller-supplied size does not exceed the allocated buffer size before the memcpy.

--- a/sys/dev/drm/amd/powerplay/amd_powerplay.c
+++ b/sys/dev/drm/amd/powerplay/amd_powerplay.c
@@ -678,6 +678,9 @@ static int pp_dpm_set_pp_table(void *handle, const char *buf, size_t size)
        return -EINVAL;

+   if (size > hwmgr->soft_pp_table_size)
+       return -EINVAL;
+
    mutex_lock(&hwmgr->smu_lock);
    if (!hwmgr->hardcode_pp_table) {
        hwmgr->hardcode_pp_table = kmemdup(hwmgr->soft_pp_table,

Rationale: soft_pp_table_size is the size the backend will re-parse the table as during amd_powerplay_reset() (called at line 697), so accepting a larger input is never meaningful — it is always either a user mistake or an attack.

Related findings

• DF-1561 (sibling): pp_dpm_get_pp_num_states stack OOB from num_ps > 16.