DF-3768 — i915 GGTT aperture fictitious-range registered, never unregistered (DFly)

Finding (summary)

DragonFly-specific code in sys/dev/drm/i915/i915_gem_gtt.c:2965-2970 (i915_gem_init_ggtt()) registers the GMADR (GTT aperture) PCI BAR as a "fictitious" physical range so that CPU mmaps of GTT-bound objects can be backed by fake vm_pages (i915_gem.c:2391 resolves user faults through vm_phys_fictitious_to_vm_page(ggtt->gmadr.start + ...)).

The matching teardown never happens: i915_ggtt_cleanup_hw() (i915_gem_gtt.c:2992-3029) does NOT call vm_phys_fictitious_unreg_range(). The shim backing these calls (sys/dev/drm/drm_vm.c:141-227) keeps a fixed array of 8 global segments (VM_PHYS_FICTITIOUS_NSEGS) and registers into the first free slot — it does not detect duplicates.

Consequences (per driver attach/detach cycle — kldload/kldunload of i915kms.ko, or any error-probe → re-probe of the PCI device):

1. Unbounded kernel-memory leak: every (re-)attach allocates a fresh fake vm_page array of (aperture_size / PAGE_SIZE) entries and keeps the old one alive (nothing frees it). A 256 MB mappable aperture ⇒ 65,536 fake pages (~6 MB+ per cycle on x86_64) — repeatable without bound.
2. Slot exhaustion → graphics DoS: after 8 cycles the segment array is full and vm_phys_fictitious_reg_range() returns EBUSY, failing i915_gem_init_ggtt() → the driver can never attach again until reboot.
3. Stale segment after unload: the un-freed registration keeps matching the BAR's physical range after the driver is gone; a subsequently attached device that lands on the same BAR address is resolved to the stale shadow array first.

Contrast in the same tree: the radeon driver performs the symmetric lifecycle (radeon_device.c:1493 register / radeon_device.c:1566 unregister), proving the omission is i915-specific and not a shim limitation.

Threat model

Trigger requires root (module load/unload or device re-probe). No unprivileged trigger exists in this file. Impact is resource exhaustion / availability of the graphics stack plus unbounded kernel heap growth — not memory corruption. Severity: Low.

Source-level proof points

• sys/dev/drm/i915/i915_gem_gtt.c:2966-2970 — the registration (inside #ifdef __DragonFly__; no upstream counterpart).
• sys/dev/drm/i915/i915_gem_gtt.c:2992-3029 — i915_ggtt_cleanup_hw() has no vm_phys_fictitious_unreg_range and no free of the shadow array.
• sys/dev/drm/drm_vm.c:144-204 — 8-slot global array; first-free-slot insert; duplicate registration silently succeeds and leaks the older array; EBUSY when full.
• sys/dev/drm/drm_vm.c:207-227 — unreg exists and frees the array, but is never called by i915.
• sys/dev/drm/radeon/radeon_device.c:1493,1566 — symmetric lifecycle done correctly by radeon.
• sys/dev/drm/i915/i915_gem.c:2391-2395 — why the registration must outlive mappings, and why the correct fix mirrors radeon's (unregister at ggtt cleanup after all VMAs/mappings are torn down), not "drop it".

Reproduce (requires real Intel graphics hardware + root)

# on a DragonFly host with i915 hardware and i915kms.ko available:
for i in 1 2 3 4 5 6 7 8 9; do
    kldunload i915kms && kldload i915kms
done
# cycle 9: console shows "taking over the fictitious range ..." absent /
# probe fails with EBUSY; vmstat/kmem statistics show ~8 leaked arrays.

The audit guest has no Intel GPU (virtio 0x1111:1234) and no i915kms.ko, so the runtime demonstration is not_reproduced on this guest — see VERDICT.md. The logic-level claim is source-certain.

Fix

fix.diff in this directory (against the read-only sys/ tree; never applied by the auditor): unregister the fictitious range in i915_ggtt_cleanup_hw() after VMA teardown, mirroring radeon.

DF-3768 — VERDICT

Status: not_reproduced (runtime) — the audit QEMU guest is virtio-only (pciconf -l: vgapci0@pci0:0:2:0: chip=0x11111234 = Red Hat/QEMU virtual VGA; ls /boot/kernel/i915kms.ko → No such file; kldstat -v | grep -ci i915 → 0). There is no Intel graphics device and no i915 module object on the guest, so the trigger (driver attach/detach cycles) cannot execute. The finding is source-level certain; the defect does not depend on hardware behavior, only on the registration/teardown asymmetry.

Why the finding is real (path:line)

1. i915_gem_gtt.c:2968 calls vm_phys_fictitious_reg_range(gmadr.start, gmadr.start+mappable, WC) once per successful i915_gem_init_ggtt().
2. vm_phys_fictitious_reg_range (drm_vm.c:172-204) allocates page_count = (end-start)/PAGE_SIZE fake vm_pages (drm_vm.c:183) and stores them in the first free slot of the 8-entry global vm_phys_fictitious_segs[] (drm_vm.c:191-200). A second registration of the same range takes the NEXT free slot and the first array is orphaned (drm_vm.c:202 only frees on slot exhaustion).
3. i915_ggtt_cleanup_hw (i915_gem_gtt.c:2992-3029) tears down the gsm iomap, mtrr, stolen, drm_mm — but never calls vm_phys_fictitious_unreg_range. Grep over the whole i915 subtree: zero call sites (only radeon_device.c:1566 and the shim's definition).
4. After 8 attach cycles, drm_vm.c:203 returns EBUSY → i915_gem_init_ggtt returns error → the driver cannot attach (graphics unavailable until reboot). Each earlier cycle permanently leaked (mappable/4096) * sizeof(struct vm_page) bytes (256 MB aperture ⇒ ~6-8 MB/cycle, ×7 cycles).

Why not worse

• No unprivileged trigger: kldload/kldunload and PCI re-probe are root-only. Not privesc, not memory corruption; leak + availability.
• The stale (never-freed) segment is self-consistent: its fake pages stay allocated, so post-unload lookups resolve to valid memory (no UAF of the shadow array itself; the shim's unreg path — which does kfree — is never taken).

Fix validation

Not performable on this guest (no i915 kernel build target device-independ …actually a kernel with i915 built-in could be built, but the trigger still requires real Intel hardware to attach; building a kernel proves nothing about the runtime behavior). fix.diff is the verified-by-inspection fix mirroring radeon's proven lifecycle; fix_status: not_testable (hardware absent).

Artifacts

• trigger.sh — the kldload/kldunload cycle a maintainer reproduces with on Intel hardware.
• env.txt — guest evidence (uname, pciconf, module absence).
• upstream_v419_vs_dfbsd.diff — full diff showing the DFly-only block.
• fix.diff — the proposed fix.

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.