Summary

vm_phys_fictitious_to_vm_page() iterates global segment table and reads seg->start seg->end seg->first_page with NO synchronization (drm_vm.c:152-170). vm_phys_fictitious_unreg_range() clears those same fields under vm_phys_fictitious_reg_mtx (drm_vm.c:213) then calls kfree(first_page) OUTSIDE the lock (drm_vm.c:220-221). Concurrent GPU page-fault reader can observe cleared/NULL first_page or pointer to already-freed memory causing NULL-deref panic in KASSERT (drm_vm.c:164) or UAF read of vm_page array. Reader races 3 ways: (a) reads start/end one generation first_page another -> m=&NULL[idx] -> KASSERT at 164 derefs m->flags at near-NULL addr -> panic; (b) reads first_page before NULLed but kfree runs before KASSERT touches m->flags -> UAF read of freed vm_page storage (M_DRM slab reallocated with attacker content via GEM create/destroy); (c) stale start/end zeroed but fresh segment registered same slot -> wrong-page mapping. Reader hot path: ttm_bo_vm.c:667 every TTM VRAM/IOMEM fault + i915_gem.c:2391 i915 GMADR fault. Writer: radeon_device_fini/amdgpu_device init/teardown i915 ggtt setup -- events overlapping live user mappings during driver teardown/GPU reset. Attacker: local unprivileged GPU client. Step 1 open/authenticate/create+mmap VRAM BO; Step 2 spawn threads continuously faulting mapping; Step 3 async driver event kldunload drm/GPU reset/pm suspend invokes unreg while mappings live. Race produces immediate panic (DoS) OR UAF read of freed DRM-owned vm_page array slab-groomable info leak or potential controlled physical page mapping.