Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic id = 0
fault virtual address	= 0x28
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff8074946d
stack pointer	        = 0x10:0xfffff8008d1f8a20
frame pointer	        = 0x10:0xfffff8008d1f8a40
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 0, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= Idle
current thread          = pri 12
kernel: type 12 trap, code=0

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      rn_flush+0x1d:  movq    0x28(%rbx),%rax
db>

---------------------------------------------------------------------
Context (from the serial console during DF-3462 teardown, before the
`vm.sh reset with-src`):

    ipfw3 module layer4 unloaded
    ipfw3 module basic unloaded
    <panic above during `kldunload ipfw3`>

This crash is NOT the DF-3462 finding and NOT on the DF-3462 code path:
`set_toggle_dispatch()` / `ip_fw3_ctl_set_toggle()` are only reachable
via the IP_FW_SET_TOGGLE sockopt and were never invoked during module
load/unload. It is a stock `ip_fw3_fini()` teardown defect (ip_fw3.c
fini_dispatch: dehook + flush + kfree(fw3_ctx) while ipfw3 table radix
state apparently still references freed memory; rn_flush is a radix
helper). Observed once, during `kldunload ipfw3` on the module carrying
the DF-3462 toggle fix (the fix does not touch any load/unload path —
see fix.diff). Recorded here for the maintainers as an independent
lead; the guest was reset with `vm.sh reset with-src` afterwards and
all DF-3462 baseline/patched measurements were re-taken from a clean
boot (the patched-module run never unloaded the module).