fix_run.log — DF-3485 fix validation (module with fix.diff only)
=================================================================

Load the single-fix module and run the exact same trigger:

    # kldload ng_socket
    # kldload /usr/obj/usr/src/sys/netgraph/iface/ng_iface.ko
    # ngctl mkpeer . iface inet inet
    (session dies; guest panicked - but with a DIFFERENT panic)

    panic: try holding ifnet lock in netisr
    cpuid = 0
    Trace beginning at frame 0xfffff8008d1f87e0
    ifnet_lock() at ifnet_lock+0x62 0xffffffff807304d2
    ifnet_lock() at ifnet_lock+0x62 0xffffffff807304d2
    if_attach() at if_attach+0x4db 0xffffffff80730a8b
    ng_iface_constructor() at ng_iface_constructor+0x22d 0xffffffff8265653d
    ng_mkpeer() at ng_mkpeer+0x4c 0xffffffff82618ebc
    ng_generic_msg() at ng_generic_msg+0x415 0xffffffff82619835
    Debugger("panic")

Interpretation:
  * "trying to free NULL pointer" is GONE => the DF-3485 defect is
    eliminated by fix.diff (machine code confirmed in disasm.fixed.txt:
    the kfree is now guarded by test/je).
  * The NEW panic occurs at the if_attach() call (ng_iface.c:605,
    constructor offset changed +0x3a2 -> +0x22d because the fixed
    get_unit code is laid out differently) and is the independent
    DF-3486 defect (if_attach from netisr context).
  * With DF-3486's fix applied as well, this same trigger SUCCEEDS:
    see findings/poc/DF-3486/fix_run.log (ng0 created, listed by
    ngctl/ifconfig, clean shutdown, 22+ create/destroy stress cycles,
    no panic).

Note on an instructive artifact: one intermediate run re-panicked with the
old free-NULL signature after the fix "had been applied" - that was HAMMER2
write-loss (the /usr/src edit was ~60s old when the panic hard-killed the
VM, so it never reached disk). After re-applying and syncing, the fix
behavior is stable. Recorded so the anomaly is not misread as a regression.