DF-0414 / run.log
=== DF-0414 baseline (unpatched #0) decisive run === Command: timeout 60 ./trigger_spray (as root, ng_socket + ng_pppoe loaded) Guest: DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 The trigger_spray process opened 20 000 sockets, mapped 64 anon sentinel pages, created an ng_pppoe peer on hook "mydata"<->"ethernet", and began injecting malicious PADI frames (ph->length=0xFFFF, 24-byte mbuf). After ~30-40 NgSendData iterations the guest became unresponsive to ssh (ssh died with "Connection closed"); the kernel had panicked. The panic signature is preserved in panic.txt; the full serial console capture is in baseline_panic.log. Excerpt from dmesg right before the panic: no service tag <-- repeated 30+ times: get_tag() returned NULL no service tag after walking OOB heap without finding a ... SRV_NAME match (the bug firing silently) no service tag Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfffff8011b400002 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff82656022 Stopped at get_tag+0x12: movzwl 0x2(%rax),%edx The trap is in get_tag() at the load of pt->tag_len (offset 2 from pt), exactly the OOB read predicted by the finding. instruction pointer 0xffffffff82656022 == ng_pppoe.ko:get_tag+0x12 (matches the loaded module address 0xffffffff82656000 from kldstat). The same panic reproduced deterministically across two independent trigger_spray runs on the same #0 baseline (1st run fault virtual address 0xfffff8011c100002, 2nd run 0xfffff8011b400002; identical IP).