DF-4767 — PSP BOs (tmr_bo, asd_shared_bo, firmware.rbuf) leaked permanently when psp_hw_start fails during psp_load_fw

File: sys/dev/drm/amd/amdgpu/amdgpu_psp.c (pass 2) Static finding — the audit guest has no AMD GPU (amdgpu not attached; same situation as the accepted DF-1854/DF-1855 precedent), so no runtime PoC exists; the leak is proven by code path.

Path

1. psp_load_fw() (amdgpu_psp.c:338) allocates, in order: psp->cmd (:346), fw_pri_bo (:350), fence_buf_bo (:358), cmd_buf_bo (:366), ring buffer adev->firmware.rbuf (psp_ring_init :375 → psp_v3_1_ring_init:310), tmr_bo (psp_tmr_init :379 → 3 MB VRAM, PSP_TMR_SIZE), asd_shared_bo (psp_asd_init :383 → 16 KB VRAM).
2. psp_hw_start() (:388) fails (unresponsive PSP / bad SOS fw — anything that makes bootloader/ring/TMR/ASD setup return nonzero).
3. goto failed_mem (:390 → :398) frees ONLY cmd_buf_bo, fence_buf_bo, fw_pri_bo and kfree(psp->cmd) — tmr_bo, asd_shared_bo and the ring BO are not freed.
4. Caller psp_hw_init() (:441-444) sets adev->firmware.load_type = AMDGPU_FW_LOAD_DIRECT and returns -EINVAL.
5. Every later psp_hw_fini() early-returns at :452-453 (load_type != AMDGPU_FW_LOAD_PSP), which is the only place that frees tmr_bo/asd_shared_bo/rbuf (psp_ring_destroy :455). ⇒ permanent leak of ~3 MB + 16 KB + 4 KB VRAM per failed PSP init, repeatable per probe retry / module reload cycle.

Fix

fix.diff — free the ring/asd_shared/tmr BOs in failed_mem (NULL-safe amdgpu_bo_free_kernel, pointers cleared, no double-free vs psp_hw_fini).

Verify idea (needs Vega10/12/Raven/Vega20 hardware or SR-IOV VF)

Corrupt the PSP SOS firmware (psp_12_0sos.sos-class file) so psp_bootloader_load_sos fails after psp_tmr_init/psp_asd_init succeeded, let probe fail, reload the module N times, observe amdgpu_vram_usage / TTM stats drift by ~3 MB per cycle (unpatched) and no drift with fix.diff.

DF-4767 VERDICT

Status: INCONCLUSIVE-RUNTIME / SOURCE-CONFIRMED. The audit guest has no AMD GPU (vgapci is the QEMU emulated Intel/bochs device; amdgpu never attaches), so the leak cannot be exercised here — identical situation to the accepted DF-1854/DF-1855 precedents for this file.

Source path (all citations amdgpu_psp.c unless noted): - allocations: :346 (cmd), :350 (fw_pri 1 MB GTT), :358 (fence), :366 (cmd_buf), :375 psp_ring_init → psp_v3_1.c:310 adev->firmware.rbuf (4 KB VRAM), :379 psp_tmr_init → PSP_TMR_SIZE 3 MB VRAM (:173), :383 psp_asd_init → PSP_ASD_SHARED_MEM_SIZE 16 KB VRAM (:229). - failure: :388-390 psp_hw_start error → goto failed_mem; the label chain :398-411 frees only cmd_buf/fence/fw_pri/kfree(cmd). - permanence: :441-444 flips load_type to AMDGPU_FW_LOAD_DIRECT; psp_hw_fini :452-453 then early-returns forever, and it is the ONLY caller that frees tmr_bo (:457), asd_shared_bo (:462) and the ring (psp_ring_destroy :455 → psp_v3_1.c:390 frees adev->firmware.rbuf). - repeatable per failed probe (module reload) ⇒ unbounded VRAM accumulation over time.

Impact: kernel VRAM/GTT resource leak (local DoS of GPU memory), not memory corruption. Severity Low (requires PSP init failure — mismatched or corrupt PSP firmware, root-controlled files).

Fix: fix.diff (validated as apply-clean; semantics reviewed against amdgpu_bo_free_kernel NULL-safety in amdgpu_object.c:359-379 and amdgpu_bo_unref pointer-clearing in amdgpu_object.c — no double-free introduced for the sriov skip_memalloc path, which also funnels into failed_mem).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.