Fatal user address access from kernel mode from sysctl at ffffffff808d99a6

Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic id = 0
fault virtual address	= 0x84
fault code		= supervisor write data, page not present
instruction pointer	= 0x8:0xffffffff808d99a6
stack pointer	        = 0x10:0xfffff80118443688
frame pointer	        = 0x10:0xfffff801184436a8
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		= 17009
current thread          = pri 6 (CRIT)
kernel: type 12 trap, code=2

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      wb_stop+0x156:  movl    $0,0x84(%rax)
db>
--------------------------------------------------------------
NOTE — THIS PANIC IS A RIG BUG IN df4266_wb_poc.c v1, NOT THE FINDING.

It occurred on the first dispatch attempt (Phase 0, real wb_init ->
wb_stop): the fabricated ifnet had if_snd.altq_subq == NULL, so the
kernel's inlined ifq_clr_oactive() (ifsq_clr_oactive: ifsq_hw_oactive=0,
struct ifaltq_subque+0x84) dereferenced NULL.  Fixed in the rig by
providing a real subqueue (df_subq) exactly as if_attach() does
(net/if.c:592-640).  Recorded for completeness and for the
wb_stop-struct-offset evidence in VERDICT.md (if_timer=+0x6a,
wb_bhandle=+0x3c0, wb_btag=+0x3c8, wb_ldata=+0x400, rx-chain wb_mbuf
induction at +0x450, wb_stat_timer=+0x1e68, if_snd.altq_subq=+0x210 —
all confirmed matching the module compile; the panic was a genuine
NULL-subqueue issue, not a layout mismatch).