DF-2677 POST-FIX panic capture (fix.diff applied, kernel #1 Sun Aug 30
13:38:49 UTC 2026, same PoC /tmp/shm_rmid_race 30000 16 as nobody,
kern.ipc.shm_use_phys=2):

login: DF-2676: loaded, page 0xfffff80049b20000 busied in obj 0xfffff80116ccd100
DF-2676: grabber: calling vm_page_grab(obj, 0, VM_ALLOC_NORMAL) - NO VM_ALLOC_RETRY - on busy page
DF-2676: holder: waking busy page 0xfffff80049b20000
DF-2676: grabber: grab returned 0 (no panic?!)          <-- DF-2676 fix HELD
panic: vm_object_terminate2: objeScEtC OwNiDtAhR Yref ePrAeNnIceCs, ref_cou nt=1
cpuid = 5
Trace begiOnning aNt frame 0xfffff801186237b8
 CPU 3 THREAD vm_ob0xjectf_teffff800rminate() at 8d31vm_obje66ct0_terminate+0x3407 0xff
ffffff809ac477 
vm_object_terminate() at vm_object_terminate+0x347 0xffffffff809ac477 
vm_object_deallocate() at vm_object_deallocate+0x85 0xffffffff809ac7c5 
shm_deallocate_segment() at shm_deallocate_segment+0x17 0xffffffff806b2ed7 
sys_shmctl() at sys_shmctl+0xd6 0xffffffff806b3616 
syscall2() at syscall2+0x11e 0xffffffff80bd6a2e 
Debugger("panic")

(Interleaved garble is serial-console echo of the panic line.)

NOTE: symbol addresses shifted vs the pre-fix captures
(shm_deallocate_segment 0xffffffff806b2ee7 -> 0xffffffff806b2ed7,
sys_shmctl 0xffffffff806b35f6 -> 0xffffffff806b3616) - the running kernel
DID contain the sysv_shm.c patch, and the race STILL fires.  The early
nattch++ closes the shmat-side window but at least one other reference
acquisition during object termination remains.  Since every vm_map-side
reference on a shm object implies a counted attach (nattch), the residual
+1 is not map-entry related; it is an uncounted vm_object_reference* on
the dying object from a path not serialized by shm_token (candidates:
vm_map_backing_replicated via clipping of adjacent entries during
vm_map_inherit/vm_map_remove on OTHER maps referencing the object is
nattch-covered; remaining candidates are non-shm reference sites reaching
the object, e.g. through the prealloc path or backing-arc replication
during vmspace operations).  Not pinned within the verification budget.

DF-2676 verdict on the same kernel: fix HELD (grab returned 0 cleanly,
guest survived until the DF-2677 race panicked it).