Summary

The amdgpu_regs_pcie, amdgpu_regs_didt, and amdgpu_regs_smc read/write debugfs handlers (six functions, lines 229-452) pass the full user-controlled file position *pos (divided by 4, or in the SMC case raw) directly to the RREG32_*/WREG32_* MMIO accessors with no upper-bound check, unlike the MMIO path in amdgpu_debugfs_process_reg_op which at least compares against adev->rmmio_size.

This lets a reader walk the entire PCIE config / DIDT / SMC register spaces (and beyond on chips whose accessors don't re-check bounds) and lets a root writer (files are mode 0444 so write requires privilege bypass or chmod) hit arbitrary register offsets.

The same code also has no CAP_SYS_ADMIN gate on these debugfs nodes.

Root cause

amdgpu_debugfs_regs_pcie_read (line 242):

value = RREG32_PCIE(*pos >> 2);

— *pos is the raw seek offset supplied by userspace and is never compared to any device limit before being fed to adev->pcie_rreg().

Same pattern at lines 285 (pcie_write), 321 (didt_read), 364 (didt_write), 400 (smc_read — note SMC uses *pos directly without >> 2, line 400), 443 (smc_write).

Contrast with amdgpu_debugfs_process_reg_op at line 161 which at least guards if (*pos > adev->rmmio_size) goto end;.

The underlying accessors (amdgpu.h:1106-1115) are indirect function pointers (adev->pcie_rreg etc.); whether they re-validate depends on the asic backend, and several backends route straight to ioread32/write into a mapped region without an explicit bounds check, so an attacker-chosen offset can read MMIO/PCI config beyond the intended aperture or, on writes, mutate configuration registers not meant to be exposed.

Threat model

Local unprivileged reader on a system with CONFIG_DEBUG_FS defined and debugfs accessible (files are S_IRUGO = 0444 at line 833).

Read path leaks raw GPU/PCI register state — useful for fingerprinting, side-channel (e.g. reading sensor/fuse registers), and in some cases kernel/host memory addresses programmed into BARs.

Write path requires root (mode 0444 denies unprivileged writes at the VFS layer) but on a misconfigured system or via confused-deputy can reprogram GPU config registers, cause GPU hang / platform reset (DoS), or write DMA-engine registers to redirect bus master transfers — a root-to-persistent-compromise path.

On DragonFlyBSD's default build this code is compiled out (CONFIG_DEBUG_FS undefined), so live risk is nil; it activates with a one-line config change.

PoC

Read PoC:

dd if=/sys/kernel/debug/dri/0/amdgpu_regs_pcie bs=4 count=4096

— walks 4096 PCIE register dwords starting at offset 0; hexdump the result to inspect config-space and beyond.

Equivalent for amdgpu_regs_didt and amdgpu_regs_smc. For SMC note the byte/dword inconsistency (line 400 uses *pos not *pos >> 2) so each 4-byte read advances *pos by 4 but indexes register *pos, scanning every 4th register.

Success criteria: returns data beyond the documented aperture or values that match known sensitive registers (fuses, BAR addresses) — an info leak.

Recommended fix

Add an explicit per-aperture size guard at the top of each handler, mirroring the MMIO path. Concretely, store adev->rmmio_size-equivalent limits (pcie_regs_size / didt_regs_size / smc_regs_size — or simply clamp *pos to the aperture returned by pci_resource_len for the relevant BAR) and reject *pos >= limit before the loop. Also add a CAP_SYS_ADMIN (or drm_master) check on the write handlers and consider gating read on the same capability since these expose raw hardware state.

Minimal fix for the read side of amdgpu_debugfs_regs_pcie_read:

--- a/sys/dev/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -236,6 +236,9 @@ static ssize_t amdgpu_debugfs_regs_pcie_read(struct file *f, char __user *buf,
    if (size & 0x3 || *pos & 0x3)
        return -EINVAL;

+   if (*pos >= adev->rmmio_size)
+       return 0;
+
    while (size) {
        uint32_t value;

Apply the analogous guard to the didt_*, smc_* read/write handlers (the SMC handler additionally needs *pos >> 2 normalization at lines 400/443 to match the rest of the file's "byte offset in, dword register out" convention).

Long-term: route all six handlers through a single bounds-checked helper the way process_reg_op does for the MMIO case.

Related findings

• DF-1692 (sibling: heap OOB read+write in amdgpu_gpr debugfs handler)