Summary

psp_cmd_submit_buf unconditionally enters a busy-wait polling psp->fence_buf for the per-command fence value, with no timeout and no check of the return value of psp_cmd_submit. If submission fails (e.g. psp_v3_1_cmd_submit returns -EINVAL on its write_frame out-of-bounds check at psp_v3_1.c:423-428), the fence is never written, the value at *((unsigned int *)psp->fence_buf) stays at zero, and because every caller passes a non-zero index, the loop predicate is permanently true and the calling kernel task loops forever in msleep(1). This pins a kernel thread and any mutex it holds, taking the GPU init/resume path with it.

Root cause

amdgpu_psp.c:130-135:

ret = psp_cmd_submit(psp, ucode, psp->cmd_buf_mc_addr,
                     fence_mc_addr, index);

while (*((unsigned int *)psp->fence_buf) != index) {
    msleep(1);
}

Three concrete failure modes reach this hang:

(a) psp_cmd_submit returns non-zero — psp_v3_1_cmd_submit (psp_v3_1.c:397-445) and psp_v10_0_cmd_submit (psp_v10_0.c:279-325) both return -EINVAL when their write_frame pointer is out of bounds (psp_v3_1.c:423-428 / psp_v10_0.c:303-308). ret is captured but never inspected before the loop, and the loop reads psp->fence_buf which was zero-initialised in psp_load_fw at amdgpu_psp.c:373 and only ever written by PSP firmware on successful completion. With ret != 0 the firmware never writes the fence, so 0 != index stays true forever.

(b) The PSP firmware hangs or never responds — hardware fault, in_gpu_reset racing (amdgpu_psp.c:273), broken SR-IOV VF, or mode1 reset firing mid-command.

(c) The loop has no upper bound — even the success path has no escape; the kernel relies entirely on PSP firmware co-operation to exit. psp_wait_for (amdgpu_psp.c:96-116) has the same shape but at least bounds its loop by adev->usec_timeout; this loop does not.

Threat model & preconditions

• Attacker position: local privileged user, or any path that triggers GPU reset/resume (including unprivileged paths that cause a GPU fault).
• Privileges gained or impact: persistent local denial of service against the GPU subsystem. The calling thread (amdgpu device IP-block init/resume worker, a kernel thread) never returns; any mutex held by the caller (adev->firmware.mutex at amdgpu_psp.c:423 and :502) is held forever, blocking all subsequent PSP/GPU operations and wedging driver unload/reload. Recoverable only by reboot.
• Required config or capabilities: device amdgpu on a PSP-class ASIC (VEGA10/VEGA12/RAVEN/VEGA20) with firmware.load_type = AMDGPU_FW_LOAD_PSP.
• Reachability: anything that puts the PSP ring into a state where psp_v3_1_cmd_submit's bounds check trips, or anything that hangs the PSP (concurrent psp_mode1_reset, SR-IOV VF reset, real PSP firmware fault, or rapid suspend/resume racing with ring teardown).

Proof of concept

PoC source: findings/poc/DF-1855/repro.sh

#!/bin/sh
# Race resume against PSP ring teardown so psp_cmd_submit returns -EINVAL
# and psp_cmd_submit_buf spins forever on the zero fence_buf.
for i in $(seq 1 50); do
    acpiconf -s 3 || true      # suspend to RAM
    sleep 2                    # give resume a chance to enter psp_resume
done
ps -o stat,pid,comm -ax | grep -E 'D|amdgpu'
# After a few iterations, an amdgpu kernel thread is stuck in state D
# inside msleep inside psp_cmd_submit_buf. kldunload amdgpu will hang.

Expected output

amdgpu kernel thread stuck in state D (uninterruptible wait)
kldunload amdgpu blocks indefinitely
kgdb/ddb stack trace ending in psp_cmd_submit_buf -> msleep

Impact

Medium-severity local DoS. The entire amdgpu device becomes unusable and the hung kernel thread blocks suspend/shutdown. The thread is in msleep so the CPU is not pinned, but the GPU subsystem is dead.

Recommended fix

Check the return value of psp_cmd_submit before entering the wait, and bound the wait with a timeout.

--- a/sys/dev/drm/amd/amdgpu/amdgpu_psp.c
+++ b/sys/dev/drm/amd/amdgpu/amdgpu_psp.c
@@ -118,7 +118,8 @@ static int
 psp_cmd_submit_buf(struct psp_context *psp,
           struct amdgpu_firmware_info *ucode,
           struct psp_gfx_cmd_resp *cmd, uint64_t fence_mc_addr,
           int index)
 {
-   int ret;
+   int ret, i;
+   struct amdgpu_device *adev = psp->adev;

    memset(psp->cmd_buf_mem, 0, PSP_CMD_BUFFER_SIZE);

@@ -130,11 +131,21 @@ psp_cmd_submit_buf(struct psp_context *psp,
    ret = psp_cmd_submit(psp, ucode, psp->cmd_buf_mc_addr,
                 fence_mc_addr, index);

+   if (ret) {
+       DRM_ERROR("PSP command submission failed (%d) for cmd_id=0x%x\n",
+             ret, cmd->cmd_id);
+       return ret;
+   }
+
    while (*((unsigned int *)psp->fence_buf) != index) {
        msleep(1);
+       if (++i > adev->usec_timeout / 1000) {
+           DRM_ERROR("PSP command 0x%x timed out waiting for fence %d\n",
+                 cmd->cmd_id, index);
+           return -ETIME;
+       }
    }

The timeout constant should match the scale already used elsewhere in this driver (psp_wait_for uses adev->usec_timeout microseconds at amdgpu_psp.c:103; convert to milliseconds for msleep).

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).