panic: vm_fault: fault on stack guard, addr: 0xfffff8011795a000
cpuid = 1
Trace beginning at frame 0xfffff801183431e8
vm_fault() at vm_fault+0x12eb 0xffffffff8099ef9b 
vm_fault() at vm_fault+0x12eb 0xffffffff8099ef9b 
trap_pfault() at trap_pfault+0x9a 0xffffffff80bd52ca 
trap() at trap+0x17c 0xffffffff80bd5bcc 
calltrap() at calltrap+0x9 0xffffffff80b991fa 
--- trap 000000000000000c, rip = ffffffff80bcab4f, rsp = fffff801183435f0, rbp = fffff80118343628 ---
memmove() at memmove+0x24f 0xffffffff80bcab4f 
pfr_get_tables() at pfr_get_tables+0x31 0xffffffff8262a681 
boot() called on cpu#1
Uptime: 3m58s
Physical memory: 4060 MB
Dumping 559 MB: 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
Dump complete

[then secondary GPF panics during crash-dump shutdown -- not part of this bug]

Analysis
--------
* trap 0xc = page fault.
* `memmove+0x24f` is the underlying implementation of `bcopy()` on
  x86_64 (`sys/platform/pc64/x86_64/support.S`).
* `pfr_get_tables+0x31` is the call site at `sys/net/pf/pf_table.c:1280`
  where `pfr_get_tables()` invokes `pfr_fix_anchor(filter->pfrt_anchor)`
  (which is inlined or called immediately on entry).
* The fault address 0xfffff8011795a000 is a kernel virtual address — the
  bcopy ran off the end of the source/destination kernel page into an
  unmapped (or stack-guard) page, exactly as predicted:
    bcopy(path, anchor, siz - off)
  with siz=1024 and off=1025 yields a size_t of 0xFFFFFFFFFFFFFFFF,
  which memmove implements as `rep movsb` until it page-faults.

This is the precise primitive DF-0362 describes. Trigger context:
DIOCRGETTABLES ioctl on /dev/pf (root-only).