DragonFlyBSD Kernel Audit
DF-0414 / run.log
← back to finding ↓ download raw
=== 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).