# DF-3900 VERDICT

**Status: inconclusive (source-certain; not runnable on this guest)**
**reproduced: 0 · impact class: dos (KVA/resource exhaustion, root-gated) · confidence: certain**

## Why the bug is certain from source alone

1. `i915_mmio_setup()` maps the MMIO BAR per attach:
   `dev_priv->regs = pci_iomap(pdev, mmio_bar, mmio_size)` — i915_drv.c:1027.
2. On DragonFly `pci_iomap` → `pci_resource_start` (sys/dev/drm/include/linux/pci.h:267)
   does `bus_alloc_resource_any(RF_SHAREABLE)` — never released by anyone — and
   `ioremap` → `__ioremap_common` (sys/dev/drm/linux_iomapping.c:44-57) does
   `pmap_mapdev_attr()` + `kmalloc(struct iomap)` + `SLIST_INSERT_HEAD(&iomap_list)`.
3. The ONLY `pci_iounmap` in the entire `sys/dev/drm/i915/` tree is at
   i915_drv.c:1048, inside `#if 0` (verified: `rg -n "pci_iounmap" sys/dev/drm/i915/`
   → exactly one hit, that line).
4. The unload path calls `i915_driver_cleanup_mmio()` (i915_drv.c:1106 within
   `i915_driver_cleanup_mmio` = `intel_uncore_fini` + `i915_mmio_cleanup`,
   reached from `i915_driver_unload`:1867) and `intel_uncore_fini`
   (intel_uncore.c:1643-1653) never touches the mapping.

Therefore each attach→detach cycle of i915 leaks 512KB (gen<5) or 2MB (gen≥5)
of KVA plus the `iomap` node plus a bus resource hold. No code path frees them.
Trigger: `kldload i915kms && kldunload i915mks` as root, repeated; or repeated
probe-fail→reprobe. After N cycles, N×2MB KVA is gone permanently (reboot only).

## Why not live-verified

The audit guest is QEMU with virtio VGA (`vgapci0: chip=0x11111234` = virtio-gpu),
no Intel GPU, no `/dev/dri`, `i915kms.ko` cannot attach (see env.txt). Exactly the
situation DF-3634/DF-3768 hit; recorded `inconclusive` per the honest-status table.

## Exploit chain

None — no memory corruption, no unprivileged reach. This is a permanent kernel
resource leak enabling slow system degradation / eventual attach failures
(same operational impact family as DF-3768, which exhausts the 8-slot fictitious
range; this one exhausts KVA instead — the two compound on real hardware).

## Fix validation

`fix.diff` un-`#if 0`s the pci_iounmap in `i915_mmio_cleanup`. Not build-tested
on the guest because the i915 driver is not buildable/loadable there (no drm
in the guest kernel config path used; kernel build of drm requires the module
set). fix_status: not_applicable (no reproduced memory corruption; mandatory
fix-validation trigger not met).

## kernel_refs

- sys/dev/drm/i915/i915_drv.c:1027 (pci_iomap at setup)
- sys/dev/drm/i915/i915_drv.c:1040-1050 (cleanup with #if 0'd pci_iounmap)
- sys/dev/drm/i915/i915_drv.c:1103-1108 (i915_driver_cleanup_mmio)
- sys/dev/drm/i915/i915_drv.c:1866-1867 (unload calls cleanup_mmio)
- sys/dev/drm/linux_iomapping.c:44-57 (__ioremap_common alloc)
- sys/dev/drm/include/linux/pci.h:299-312 (pci_iomap; pci_resource_start leak)
- sys/dev/drm/i915/intel_uncore.c:1643 (intel_uncore_fini — no unmap)

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