DF-0529 / fix_run.log
=== DF-0529 FIX VALIDATION (fix.diff applied to ng_fec module) ===
fix: remove the two `kfree(ifp, M_NETGRAPH)` lines (interior pointer) from
ng_fec_constructor's error paths; keep the single kfree(priv).
build: cd /usr/src/sys/netgraph/fec && make (after applying fix.diff)
-> compiles cleanly (RC=0); ng_fec.ko produced.
built module sha256: 55b1fa922c659083b2543f3507352b444f2d9f33ca72d5422b009348f5b7a52b
installed to /boot/kernel/ng_fec.ko (hash verified identical)
linker hints rebuilt: kldxref /boot/kernel
test: kldload netgraph; kldload ng_fec; ngctl mkpeer .: fec myhook peerhook
-> STILL PANICS (guest dies). Signature shifted to +0x38e (was +0x3ae),
confirming the PATCHED code is running, but the panic persists:
panic: trying to free NULL pointer
_kfree() at _kfree+0x558
_kfree() at _kfree+0x558
ng_fec_constructor() at ng_fec_constructor+0x38e 0xffffffff8263ec7e
ng_mkpeer() ...
ISOLATION ATTEMPT: also removed ALL kfrees from the constructor error paths
(intentionally leak priv). Panic STILL occurs with identical two-_kfree
signature. Conclusion: the documented kfree(ifp)/double-kfree is NOT the
sole panic source. A residual kfree cascade remains in the constructor
path (most likely in the inlined static __inline__ ng_fec_get_unit /
ng_fec_free_unit cold paths, which contain guarded kfree(ng_fec_units)
calls; the slab allocator then receives a NULL and panics). The finding's
root-cause analysis is INCOMPLETE: the kfree(ifp) defect is real but there
is an additional, undocumented defect in the same constructor.
VERDICT: fix_failed. The fix.diff correctly removes the documented
interior-pointer/double-kfree (and compiles), but the constructor still
panics on node creation. A maintainer must also address the residual
kfree cascade (next iteration: kgdb the live DDB panic to walk the stack
and identify the exact inlined kfree site; likely ng_fec_free_unit's
kfree(ng_fec_units) firing with a NULL/stale bitmap pointer, or
ng_fec_get_unit's teardown path).