# DF-4444 evidence pack

- **What**: DragonFly-only `drm_vma_node_unmap()` in
  `sys/dev/drm/i915/i915_vma.c:857-890` cannot revoke any user CPU mapping:
  the `OBJT_MGTDEVICE` vm_object never contains pages (fault path enters
  fictitious aperture pages directly into the pmap), so both
  `vm_object_page_remove()` and the `vm_page_lookup_busy_wait()` loop are
  no-ops. After VMA unbind/evict (or object free — twin at
  `i915_gem.c:2149`), user PTEs into the physical GTT aperture stay valid
  and read/write whatever object is later bound into that aperture range.
- **Impact** (on real Intel-GPU hardware): unprivileged cross-object /
  cross-user GPU memory disclosure and corruption (High).
- **This guest**: QEMU virtio-gpu only — trigger builds and runs to its
  hardware gate (`run.log`); runtime verdict `inconclusive`.

## Reproduce

```
scp df4444_trigger.c dfbsd:/tmp/
ssh dfbsd 'cc -O2 -Wall -o /tmp/df4444 /tmp/df4444_trigger.c && /tmp/df4444'
```

Expected on hardware: exit 0 with `VULNERABLE: stale mapping of A shows V's
marker` (+ cross-object write confirmation). Expected on this guest:
`no DRI device` exit=2 (see `run.log`). On a *fixed* kernel: A's page touch
after eviction either re-faults (reads A's own fill) or SIGBUSes — never V's
marker.

## Files

- `df4444_trigger.c` — self-contained trigger (inline DRM uapi; no libdrm)
- `build.sh` / `build.log` — guest compile (clean, 1 benign warning)
- `run.sh` / `run.log` — guest run: exact hardware-gate failure, exit=2
- `env.txt` — guest uname, drm sysctls, no `/dev/dri`
- `VERDICT.md` — full line-cited static proof + attack chain
- `fix.diff` — pmap-level revocation of the VMA's aperture window
- `manifest.json`, `verdict.json`