{
  "finding_id": "DF-3435",
  "status": "not_reproduced",
  "reproduced": 0,
  "impact": "none",
  "confidence": "certain",
  "verdict": "Mechanism is code-certain but the on-guest demonstration did not complete within the session budget, so the honest status is not_reproduced with impact=none OBSERVED (the latent impact is a NULL-page write panic). ip_fw3_state.c:319 kmalloc(..., M_INTWAIT|M_NULLOK|M_ZERO) can return NULL at the malloc-type limit (kern_slaballoc.c:694-705 returns NULL exactly because M_NULLOK was requested) and :321 immediately writes s->src_addr through it (write to vaddr 0x18 -> Fatal trap 12 supervisor write). The shipped state_max_* defaults (4096/tree) keep the path cold; they are CTLFLAG_RW sysctls, so deployments that raise them expose it. On the guest: sysctls raised, 35M+ unique-5-tuple packets injected via two harnesses (state_null.c raw ~1k pps, state_null_tap.c tap frames ~250k pps write rate); the tree reached only ~190K live states (~12MB of the 390MB limit) because the netisr drain throttles state creation to ~2-7k pps (rule eval + RB insert + forward/ARP per packet; the O(n)-per-packet limit counting at :302 adds drag when rule 99 is populated). Reaching 6.1M live states needs ~30-50 min of sustained saturation and ~390MB of pinned kernel memory on the 4.25GB guest - not completed. Fix is one guard: if (s == NULL) goto done; keeping M_NULLOK (dropping it would turn the limit-hit into panic(malloc limit exceeded)).",
  "exploit_chain": "",
  "evidence": [
    "VERDICT.md: code walk (ip_fw3_state.c:319-321; kern_slaballoc.c:694-705,365-372) + on-guest throughput measurements",
    "state_null_tap.c: the fast injector used for the attempt",
    "fix.diff: NULL guard with M_NULLOK retained"
  ],
  "kernel_refs": [
    "sys/net/ipfw3_basic/ip_fw3_state.c:317",
    "sys/net/ipfw3_basic/ip_fw3_state.c:319",
    "sys/net/ipfw3_basic/ip_fw3_state.c:321",
    "sys/kern/kern_slaballoc.c:694",
    "sys/kern/kern_slaballoc.c:704",
    "sys/kern/kern_slaballoc.c:365"
  ],
  "poc_changes": "Two injectors written (raw-socket synchronous path too slow at ~1k pps; tap-frame injector reached ~250k pps write rate). Listener-based delivery and forwarding-based delivery both attempted to keep the netisr drain cheap; the drain, not the injector, is the bottleneck.",
  "attempts": 3,
  "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64",
  "runtime_sec": 420,
  "guest_dirty": 0,
  "build_cmd": "cc -O2 -o /tmp/state_null_tap /tmp/state_null_tap.c",
  "run_cmd": "/tmp/state_null_tap 30000000 (with root-raised sysctls)",
  "code_hash": "36ddc4e6da3b4b998b91aa83461154919cc7dcea014e8b3b31c0957cbf81b497",
  "notes": "Follow-up opportunity: a longer soak (30-50 min) or a faster state-creation vector (none exists besides check_keep_state) would complete the demonstration. The M_NULLOK flag was explicitly requested by the author, making the missing check an obvious oversight rather than a theoretical concern.",
  "recommended_fix": "Check the kmalloc result in check_keep_state() before writing through it (keep M_NULLOK); see fix.diff.",
  "fix_status": "not_testable",
  "fix_kernel_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #1: Sat Sep 12 16:56:02 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64",
  "fix_baseline_reproduced": 0,
  "fix_patched_reproduced": 0,
  "fix_verdict": "The baseline bug itself was not reproduced this session (throughput-bound), so a before/after fix demonstration at the malloc-type limit is not possible. The patched module ran the rewritten allocation path under load without regressions (rule evaluation and state creation worked on the fix kernels); the NULL-guard branch is straightforwardly correct by inspection but was not reachable without exhausting the 390MB type limit.",
  "fix_evidence": [
    "fix.diff"
  ]
}