dev_pager_dealloc runs cdev_pg_dtor before unlinking the object from dev_pager_object_list (and outside dev_pager_mtx): racing cdev_pager_allocate for the same handle clobbers the fresh object's si_object, making the later old_dev_pager_dtor KKASSERT(dev->si_object) a reachable panic

Summary

dev_pager_dealloc() calls ops->cdev_pg_dtor(dev) at :211 BEFORE taking dev_pager_mtx and TAILQ_REMOVE-ing the object (deliberate ordering — the comment warns DRM dtors may recurse into the pager). old_dev_pager_dtor then does KKASSERT(dev->si_object); dev->si_object = NULL with no lock. Meanwhile cdev_pager_allocate() holding dev_pager_mtx can observe the dying object OBJ_DEAD-skipped, create a NEW object for the same cdev and set dev->si_object = new_object — entirely unsynchronized against the dtor's store. If the dtor's NULL store lands after the allocator's store, the new object's back-pointer is lost, and when that object is later deallocated old_dev_pager_dtor's KKASSERT at :343 panics. Local DoS on INVARIANTS/debug builds only (window is a few instructions); on production kernels si_object is write-only bookkeeping — silent and benign. Not run (Low/debug-only per contract); reproduction sketch: two unprivileged processes looping {mmap, munmap} of the same old-pager device. Fix: do the si_object bookkeeping under dev_pager_mtx after the object is unlisted (conditional == object clear), reducing old_dev_pager_dtor to release_dev(dev).

Timeline

• 2026-09-02 Discovered during pass-2 audit of device_pager.c (GLM 5.3).