DF-5064 — drm_device_detach never unregisters or releases the drm_device: stale /dev/dri minors call into unloaded module memory + unbounded leak

What

drm_device_detach() (sys/dev/drm/drm_dragonfly.c:251-295) is the only newbus device_detach method for all three KMS drivers (i915_pci.c:880, radeon_drv.c:865, amdgpu_drv.c:1421). It runs drm_sysctl_cleanup, frees dev->agp, optionally calls dev->driver->unload, disables busmaster, lockuninits three locks and frees the pci_dev (drm_fini_pdev). It never calls drm_dev_unregister() nor drm_dev_put() — the DragonFly equivalents of Linux's i915_pci_remove() → i915_driver_unload(dev); drm_dev_put(dev); (i915_pci.c:680-691) and drm_get_pci_dev's teardown. Nothing else in the DF drm tree does it either (drm_fini_pdev appears only in the three attach error paths and here; no drm_dev_unregister on any detach path).

Consequences after kldunload i915kms (drm.ko itself stays resident via MODULE_DEPEND(i915, drm, ...)):

1. Stale live entry points into freed module memory. The /dev/dri/cardN / renderDN cdevs (created by drm_sysfs_minor_alloc, drm_sysfs.c:97, with drm_cdevsw owned by the still-loaded drm.ko) keep working: drm_open → drm_minor_acquire finds the never-unregistered minor in drm_minors_idr → dev->driver->open — a function pointer into the unloaded i915 module's text (.open = i915_driver_open, i915_drv.c:3284ff). Any unprivileged user who opens the stale node afterwards executes freed kernel memory (UAF-class). The same holds for every dev->driver->* and dev->dev_private dereference on the leaked device.
2. Unbounded leak per load/unload cycle: the whole drm_device graph (drm_device + minors + drm_sysfs_minor_alloc kdev + vblank etc.) is never freed (drm_dev_put drops the only primary reference; release (i915_driver_release / drm_dev_fini) never runs).
3. For i915 the driver itself is never torn down at all: i915's struct drm_driver has no .unload member on DragonFly (i915_drv.c:3279-3313), so drm_device_detach skips the entire i915_driver_unload() path — GPU MMIO mappings/IRQs are left live while the module goes away.
4. lockuninit() on struct_mutex/vbl_lock/event_lock (drm_dragonfly.c:288-290) races any in-flight ioctl still holding them (no synchronization with open clients at detach).

Reachability / threat model

Requires (a) a DRM adapter (i915/radeon/amdgpu hardware) and (b) root to kldunload the kms module — then the UAF window (1) is triggerable by any unprivileged user with access to /dev/dri (mode 0666 by default via DRM_DEV_MODE). The QEMU audit guest has no display-class PCI device (env.txt), so this is validated statically + the fix compile-validated (drm.ko and i915.ko build clean with it, fix_build.log).

Fix

fix.diff: after drm_fini_pdev(&dev->pdev), call drm_dev_unregister(dev) (minors become ENODEV for future opens — drm_minor_acquire then fails cleanly) and drm_dev_put(dev) (drops the primary reference; drm_dev_release frees the graph via the driver's .release). Full i915 parity additionally wants wiring i915_driver_unload (the DF driver table lacks .unload); that is noted in the diff comment and left to maintainers, since a partial teardown is strictly better than a guaranteed post-unload UAF.

Artifacts

• trace.md — full static call-chain trace with path:line citations.
• fix_build.log — full drm tree build on the guest with the patched file (BUILD_RC=0, drm.ko + i915.ko linked).
• env.txt — guest evidence of the absent DRM adapter.

DF-5064 — VERDICT

Status: NOT REPRODUCED on the audit guest (no DRM adapter — the QEMU machine exposes no display-class PCI device, so no drm device ever attaches and drm_device_detach cannot run). The defect is proven by a complete static trace; the fix compiles clean against the whole drm tree. Severity Medium (kernel UAF-class + unbounded leak, gated on GPU hardware + a root kldunload; the stale /dev/dri nodes are then openable by unprivileged users).

Trace (line-accurate)

1. sys/dev/drm/i915/i915_pci.c:880, radeon_drv.c:865, amdgpu_drv.c:1421 — DEVMETHOD(device_detach, drm_device_detach): the only detach method for all KMS drivers.
2. sys/dev/drm/drm_dragonfly.c:251-295 — drm_device_detach(): sysctl cleanup, kfree(dev->agp), optional dev->driver->unload, pci_disable_busmaster, lockuninit ×3, drm_fini_pdev(&dev->pdev). No drm_dev_unregister(), no drm_dev_put(), no drm_dev_fini().
3. sys/dev/drm/i915/i915_pci.c:680-691 — the Linux flow this file replaces: i915_pci_remove() = i915_driver_unload(dev); drm_dev_put(dev); pci_set_drvdata(pdev, NULL). (amdgpu/radeon PCI remove equivalents do the same; DF simply never calls them.)
4. sys/dev/drm/drm_sysfs.c:97 — /dev/dri/cardN cdev created by drm_sysfs_minor_alloc() via make_dev(&drm_cdevsw, ...); the only removal path is drm_minor_unregister() (drm_drv.c:236-258), reachable solely through drm_dev_unregister() (drm_drv.c:941-970) — never called at detach.
5. sys/dev/drm/drm_drv.c:274-282 (drm_minor_acquire) — an open on a still-registered minor takes a ref and succeeds; after unregister it returns ERR_PTR(-ENODEV). Today nothing unregisters → stale opens succeed → drm_open → dev->driver->open (i915_drv.c:3284: .open = i915_driver_open, .fops = &i915_driver_fops) — text in the unloaded i915kms module.
6. sys/dev/drm/i915/i915_drv.c:3279-3313 — i915's struct drm_driver has no .unload → drm_dragonfly.c:279 skips driver teardown entirely; MMIO/IRQ stay live across kldunload i915kms.
7. Reference lifecycle: drm_dev_init (drm_drv.c:538-560) takes the primary ref (kref_init); only drm_dev_put → drm_dev_release (drm_drv.c:744-756) → .release/drm_dev_fini frees it. Nothing on the newbus path drops it → leak per load/unload cycle.
8. drm_fini_pdev grep: only i915_pci.c:867 / radeon_drv.c:836 / amdgpu_drv.c:1067 (attach error paths) and drm_dragonfly.c:293 — no double-free risk from the proposed addition.

Why it matters (threat model)

kldunload i915kms (root; drm.ko stays resident via MODULE_DEPEND(i915, drm, 1, 1, 1), i915_pci.c:893) leaves /dev/dri/card0 openable (created 0666 via DRM_DEV_UID/GID/MODE). Every subsequent open/ioctl/mmap by an unprivileged user dispatches through cdevsw (drm.ko, alive) into dev->driver->* and dev->dev_private — memory belonging to the unloaded module (freed by the linker). That is a classic use-after-free execution primitive handed to unprivileged users after a root-triggered unload. Additionally each load/unload cycle leaks the full drm_device graph (unbounded with kldload/kldunload loops), and for i915 the GPU is never quiesced.

Verification performed

• Static trace above (all path:line cited).
• Guest evidence of no DRM adapter: env.txt (pciconf -lv — no class=display; /dev/dri absent). No runtime execution possible.
• Fix compile-validation: patched drm_dragonfly.c built in the guest's /usr/src/sys/dev/drm — full make rc=0, drm.ko and i915.ko linked (fix_build.log). Not runtime-testable here (no GPU), hence fix_status=not_testable.
• Positive control for the build: unpatched-vs-patched tree builds were both clean; source restored after the test.

Fix

fix.diff — add drm_dev_unregister(dev); drm_dev_put(dev); at the tail of drm_device_detach() (after drm_fini_pdev). This converts stale opens into clean ENODEV (drm_minor_acquire fails) and frees the device graph. Maintainer follow-up noted in the diff: give i915 a .unload hook (i915_driver_unload exists, i915_drv.c:1828) for full teardown parity.

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.