# DF-4785 — VERDICT

**Finding:** psp_v11_0.c never initializes the ASD firmware fields for
Vega20 while the shared amdgpu_psp.c start path unconditionally consumes
them (memcpy from NULL, zero-length LOAD_ASD with swallowed error status).

## Reproduced? NO — untestable on this guest (no AMD hardware)

- Guest `pciconf -l` (evidence in README/notes): only Intel/QEMU virtual
  PCI devices (vgapci0 chip=0x11111234 = QEMU/bochs VGA, virtio NIC/blk).
  `amdgpu` never attaches; `psp_v11_0_set_psp_funcs()` (only reached for
  CHIP_VEGA20 via amdgpu_psp.c:61-62) is unreachable at runtime. kldloading
  amdgpu.ko cannot change that — there is no AMD PCI device to probe.
- No PoC was therefore built/run; per contract this Low-severity finding
  is skipped for Phase V and recorded with the closest allowed status
  ("untested").

## Source-level proof (why the finding itself is certain)

1. `psp_v11_0_init_microcode()` (psp_v11_0.c:95-143) requests only
   "amdgpufw_vega20_sos"; it never assigns `asd_fw`, `asd_start_addr`,
   `asd_ucode_size`. adev is kzalloc'd → both stay NULL/0.
2. Sibling implementations in the same tree DO load ASD: psp_v3_1.c:126-143
   ("amdgpufw_%s_asd"), psp_v10_0.c:126-143. Upstream mainline (v5.2
   psp_v11_0.c, verified via raw.githubusercontent.com) also loads
   `vega20_asd.bin` and sets asd_ucode_size/asd_start_addr. So this is a
   real divergence of the DF port, not upstream behavior.
3. `psp_hw_start()` (amdgpu_psp.c:291) calls `psp_asd_load()` for every PSP
   ASIC; `psp_asd_load()` (amdgpu_psp.c:254-255) does
   `memcpy(psp->fw_pri_buf, psp->asd_start_addr, psp->asd_ucode_size)`
   = memcpy(p, NULL, 0) — UB; and submits GFX_CMD_ID_LOAD_ASD with
   app_len = 0.
4. PSP rejection of that command is swallowed because
   `psp_cmd_submit_buf()` gates the resp.status check on `ucode != NULL`
   (amdgpu_psp.c:137-142, the DF-4768 finding) — the TMR/ASD-for-v11
   instance the pass-2 brief asked to check.

Impact ceiling: latent boot-time panic (UB memcpy), silent PSP error state,
potential infinite fence-wait hang — all on Vega20-class hardware only, no
attacker control. Severity Low, confidence certain (divergence provable
from source), exploitability speculative/none.

## Fix

`fix.diff` mirrors psp_v3_1's ASD load block into psp_v11_0_init_microcode
(+MODULE_FIRMWARE, +release on error). Not runtime-validated (no hardware);
compiles by inspection against the same headers/types used by psp_v3_1.c
(identical field names and firmware-header types).

## 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.