=== DF-0696 ng_etf race attempt ===
=== guest: DragonFly 6.5-DEVELOPMENT #0 (with-src, unpatched) ===
=== as root, with ng_socket/ng_etf/ng_ether loaded ===

$ id
uid=0(root) gid=0(wheel) groups=0(wheel),...

$ sh ./run.sh 200
[*] racing for 200 iterations; bug fires when ng_etf_rcvdata sees
    NG_HOOK_PRIVATE(hook)==NULL (no return after NG_FREE_DATA)
[*] iter 100 / 200
[*] iter 200 / 200
[+] loop done. If kernel still up: race did not fire (window is tight).
[+] See VERDICT.md for the structural proof that the bug is real.
RUN_EXIT=0

Status: up (no panic)

Note: ngctl-based loop races control messages, not raw mbuf data. Driving
actual mbuf data into the etf hook requires an ng_socket data sock or a
real ether_hook push. The race window itself is narrow (sender must read
HK_INVALID=0, then disconnect sets HK_INVALID=1 AND private=NULL, then
rcvdata observes private==NULL). A targeted C PoC using ng_socket data
sockets would be the next iteration; the BUG is provably real from the
source (the missing `return` at ng_etf.c:383 after NG_FREE_DATA is
unambiguous). Treated here as a root-only DoS hardening gap.