# DF-4916 — `amdgpu_virt_init_data_exchange`: host-controlled `pf2vf_size` drives a 1 KB memset past the kmap'ed fw VRAM reservation (no region-bounds validation)

## Build / Run / Expected

No runnable PoC on this guest — requires an SR-IOV VF AMD GPU guest whose
host/PF (or vBIOS) supplies the pf2vf message. On real hardware:

1. Boot a DragonFly SR-IOV VF guest whose vBIOS `VRAM_UsageByFirmware` table
   declares the SR-IOV message reservation
   (`ATOM_VRAM_BLOCK_SRIOV_MSG_SHARE_RESERVATION`) with
   `used_by_firmware_in_kb` small, e.g. 4 (→ `fw_vram_usage.size = 4096`),
   and whose GIM/PF writes a pf2vf header at VRAM offset 64 KB with
   `size ∈ (0,4096)` and a matching checksum (the key is host-known: on AI it
   is literally read out of mailbox 2, `mxgpu_ai.c:176-180`).
2. `kldload amdgpu` in the guest.
3. Expected: `amdgpu_virt_init_data_exchange()` runs at the end of device
   init (`amdgpu_device.c:1695`) and after VF FLR re-init
   (`amdgpu_device.c:3345`):
   - reads at `fw_vram_usage.va + 65536` are already past the 4 KB mapping
     (`amdgpu_virt.c:402-408`),
   - on checksum match, `p_vf2pf = p_pf2vf + pf2vf_size` and
     `memset(p_vf2pf, 0, 1024)` (`amdgpu_virt.c:416-420`) writes up to
     offset 65536+4095+1024 ≈ 69 KB into the 4 KB mapping → kernel OOB access
     on the VRAM kmap → guest panic (or silent VRAM corruption of whatever is
     mapped next).

**Success criterion:** panic (or dmesg evidence of the OOB) at driver init.

## Files in this pack

- `VERDICT.md` — full bound-math narrative with path:line citations.
- `trigger.md` — the host-side setup above.
- `env.txt` — guest hardware inventory (no AMD GPU present).
- `manifest.json`, `verdict.json` — machine records.