DF-2677 panic captures (verbatim from QEMU serial console, guest
DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC, 2026-08-30).

=== Capture 1 (2026-08-30 12:46 UTC) ====================================
Run: sysctl kern.ipc.shm_use_phys=2 (root), then unprivileged user:
    /tmp/shm_grab_race 0 3000     (v1 PoC: creator shmget+IPC_RMID churn,
                                    6 faulter processes shmat+write-fault)
Panic arrived during the run via the LAST detach path (sys_shmdt):

login: panic: vm_object_terminate2: object with references, ref_count=1
cpuid = 2
Trace beginning at frame 0xfffff801182e57e8
vm_object_terminate() at vm_object_terminate+0x347 0xffffffff809ac457 
vm_object_terminate() at vm_object_terminate+0x347 0xffffffff809ac457 
vm_object_deallocate() at vm_object_deallocate+0x85 0xffffffff809ac7a5 
shm_deallocate_segment() at shm_deallocate_segment+0x17 0xffffffff806b2ee7 
shm_delete_mapping.isra.0() at ... 0xffffffff806b308c 
sys_shmdt() at sys_shmdt+0xb1 0xffffffff806b3161 
Debugger("panic")

=== Capture 2 (2026-08-30 13:0x UTC) ====================================
Run: same PoC, sysctl=2, stale RMID variant; panic via sys_shmctl(IPC_RMID):

login: pSECONDAaRYn iPcA:N IvCm_ OobNjec tCPU_ te1r TmHRiEAD n0xaffftfef80208e:10 1a80o
bject with references, ref_count=1
cpuid = 2
Trace beginning at frame 0xfffff80117b5b7b8
vm_object_terminate() at vm_object_terminate+0x347 0xffffffff809ac457 
vm_object_terminate() at vm_object_terminate+0x347 0xffffffff809ac457 
vm_object_deallocate() at vm_object_deallocate+0x85 0xffffffff809ac7a5 
shm_deallocate_segment() at shm_deallocate_segment+0x17 0xffffffff806b2ee7 
sys_shmctl() at sys_shmctl+0xd6 0xffffffff806b35f6 
syscall2() at syscall2+0x11e 0xffffffff80bd6a0e 
Debugger("panic")
CPU2 stopping CPUs: 0x0000003b
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db> 

(The garbled first line of capture 2 is interleaved serial-console text of
"panic: vm_object_terminate2: object with references, ref_count=1" with the
login prompt.)

Race window (source):
  sys_shmat()   sys/kern/sysv_shm.c:~361  lwkt_gettoken(&shm_token)
                sys/kern/sysv_shm.c:~1023 shm_handle = shmseg->shm_internal
                sys/kern/sysv_shm.c:~1025 vm_object_hold(obj)   <-- BLOCKS,
                                                            shm_token dropped
                sys/kern/sysv_shm.c:~1026 vm_object_reference_locked(obj)
                sys/kern/sysv_shm.c:~1027 vm_map_find(...)      <-- can block
                ...                                            <-- can block
                sys/kern/sysv_shm.c:~1055 shmseg->shm_nattch++   <-- LAST
  sys_shmctl()  sys/kern/sysv_shm.c:~443 IPC_RMID: nattch<=0 check under
                shm_token -> shm_deallocate_segment() while shmat is
                in-flight -> object terminated with a live reference.

Reproduction matrix:
  kern.ipc.shm_use_phys=2 (documented tunable, root sets it, default is 1):
      reproduced twice within <=100 s of racing (captures above).
  kern.ipc.shm_use_phys=1 (default): attempted ~5 min total (8 and 16
      faulter processes); no panic - the vm_object_hold() window is far
      narrower because nothing holds the object's token for long stretches.
      The window still exists in principle (shmat can block in
      vm_map_find()/vm_object_hold() whenever the object token is
      contended), so default-config reachability is "likely" but was not
      reproduced within the time budget.