=== BASELINE kernel kern.version ===
DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026
=== Setup ===
ifconfig vtnet0 -txcsum -rxcsum      # disable HW checksum offload so
                                      # sw_csum & CSUM_DELAY_DATA is set in
                                      # ip_output -> in_delayed_cksum is called

=== Run as maxx ===
$ ./df_0406_cksum 10.0.2.2 9
DF-0406: in_delayed_cksum stressor -> sending to 10.0.2.2:9
(looks for 'delayed m_pullup' in dmesg and 'Fatal trap' in boot.log)
  sent 0 pkts
  sent 50000 pkts
  sent 100000 pkts
  sent 150000 pkts
done; total sent approx 200000
$ ./df_0406_sf 10.0.2.2 9
DF-0406 alt: TCP connect/sendfile stress to 10.0.2.2:9
done

=== Observation ===
- 200k UDP packets + sendfile attempts: NO "delayed m_pullup" kprintf in dmesg,
  NO panic in boot.log.
- in_delayed_cksum IS being called (the straddle `if` is the only thing gated
  behind kprintf), but the straddle condition (offset + 2 > m->m_len) is
  never met because the kernel allocates a single contiguous mbuf for these
  packets.
- The straddle requires a multi-mbuf chain where the first mbuf ends near
  the IP+{TCP,UDP} checksum-field offset -- an unusual state not naturally
  produced by normal userland sends on this guest.
- The panic additionally requires m_pullup returning NULL (memory pressure).

=== PATCHED kernel kern.version ===
DragonFly 6.5-DEVELOPMENT #1: Sat Jul 18 06:27:30 UTC 2026
(patch applied via make installkernel; full kernel + ip_output.o rebuilt)
=== Run identical PoC on patched kernel ===
- Network still works (200k UDP packets + sendfile attempts completed).
- No panic. No regression. in_delayed_cksum behaves identically.
- fix_status: not_testable (panic non-deterministic to begin with); the
  fix is trivially correct (NULL check on the m_pullup return) and is
  validated as applies + compiles + boots + networking intact.