DF-3500 — ng_fec control plane violates the ifnet locking contract everywhere: INVARIANTS panics on create/teardown via any netgraph control path

• File: sys/netgraph/fec/ng_fec.c (v1 netgraph, LIVE module)
• Lines: 1132-1140 (constructor: ng_ether_input_p, ether_ifattach), 342/411 (ifnet_lock in addport), 430/468 (ifnet_lock in delport), 453-455 (delport: bare if_ioctl on member), 521-533 (ng_fec_init serialize dance), 549-557 (ng_fec_stop unbalanced ifnet_deserialize_all), 1222 (ng_fec_stop called from rmnode)
• Severity: Medium (deterministic INVARIANTS panics / lock-protocol violations; control plane is root-only on stock DFly)

Three reproduced facets (stock code paths)

1. Constructor in netisr — every netgraph control message is processed in a TD_TYPE_NETISR thread; the constructor calls ether_ifattach → if_attach → ifnet_lock(), which KASSERTs td_type != TD_TYPE_NETISR (sys/net/if.c:3787-3788). Any ngctl mkpeer fec … on an INVARIANTS kernel panics (after the DF-3499 kfree(NULL) is fixed; at HEAD DF-3499 fires first).
2. rmnode → ng_fec_stop — ng_fec_stop() opens with ifnet_deserialize_all(ifp) (marked "XXX", ng_fec.c:549) but is called from ng_fec_rmnode (ng_fec.c:1222) without the serializer held → lwkt_serialize_exit IS_SERIALIZED assertion panic on every node teardown.
3. delport member ioctl — bifp->if_ioctl(bifp, SIOCSIFFLAGS, NULL, NULL) (ng_fec.c:454-455) without ifnet_serialize_all(bifp) → the member driver's serializer assertion fires (reproduced with vtnet: vtnet_serialize_assert → panic). Same pattern in ng_fec_init (524-532) is at least serialize-balanced, but still runs from netisr.

Run (facet 1)

# module with only the DF-3499 bcopy guard applied (see DF-3499/fix.diff)
cd /usr/src/sys/netgraph/fec && make
kldload ng_socket; kldload ./ng_fec.ko
ngctl mkpeer fec c0 c1
-> panic: try holding ifnet lock in netisr
   ifnet_lock() <- if_attach() <- ether_ifattach_bpf() <- ng_fec_constructor()

Facets 2 and 3 are demonstrated with the fecdrive.ko thread-context driver (needed because the stock csock path cannot get past facet 1 / DF-3499): sysctl -n debug.fecdrive=shutdown after create+add vtnet0 panics in facet 2 with the stock ng_fec_stop line present; with that one call lab-disabled, the same command panics in facet 3 at vtnet_serialize_assert through ng_fec_delport. See panic_ctor_netisr.txt and panic_rmnode_delport.txt.

Notes

• On non-INVARIANTS production kernels these paths do not trip KASSERTs but still take ifnet_mtx (a sleep-capable mutex) and member serializers from netisr context — a lock-order / sleep-in-netisr hazard, not just debug noise.
• This finding is why the DF-3501/DF-3502 verifications use fecdrive.ko (kldload/sysctl thread context) plus three documented lab enablers.

DF-3500 VERDICT — reproduced (panic; three facets)

Context

Guest: DragonFly 6.5-DEVELOPMENT #0 (INVARIANTS). The stock installed /boot/kernel/ng_fec.ko and the HEAD-rebuilt module both panic during creation for the independent DF-3499 reason first; the facet-1 panic here is exhibited with ONLY the DF-3499 bcopy guard applied (one-line enabler, does not touch any code in this finding's scope).

Facet 1 — constructor runs in netisr and takes ifnet_lock

ngctl mkpeer fec c0 c1 (message delivered via the ng csock, processed in a TD_TYPE_NETISR thread) → ng_fec_constructor → ether_ifattach → if_attach → ifnet_lock → KASSERT (sys/net/if.c:3787-3788):

panic: try holding ifnet lock in netisr
ifnet_lock() at ifnet_lock+0x62
if_attach() at if_attach+0x4db
ether_ifattach_bpf() at ether_ifattach_bpf+0x45
ng_fec_constructor() at ng_fec_constructor+0x1f9
ng_mkpeer() at ng_mkpeer+0x4c

(panic_ctor_netisr.txt; reproduced twice.)

Facet 2 — rmnode → ng_fec_stop without serializer

Driven from a normal thread (fecdrive.ko "shutdown"; module had only the DF-3499 guard — the ng_fec_stop/rmnode code was stock):

panic: assertion "IS_SERIALIZED((s))" failed in lwkt_serialize_exit (lwkt_serializer.c:138)
lwkt_serialize_exit() <- ng_fec_stop() <- ng_fec_rmnode() <- ng_rmnode()

ng_fec_stop (ng_fec.c:549) does ifnet_deserialize_all(ifp) on entry but ng_fec_rmnode (ng_fec.c:1222) calls it without the interface serialized. (panic_rmnode_delport.txt, facet 2 section.)

Facet 3 — delport calls member if_ioctl unserialized

With facet 2's single call lab-disabled (documented enabler), the same teardown panics inside the member driver:

panic: assertion "IS_SERIALIZED((_arr[_i]))" failed in ifnet_serialize_array_assert (if_var.h:864)
vtnet_serialize_assert() <- vtnet_stop() <- vtnet_ioctl()
    <- ng_fec_delport.part.3() <- ng_fec_rmnode()

ng_fec_delport (ng_fec.c:454-455) invokes bifp->if_ioctl(SIOCSIFFLAGS) without ifnet_serialize_all(bifp). (panic_rmnode_delport.txt, facet 3.)

Impact

On INVARIANTS kernels every create/teardown operation through the netgraph control plane panics (facet 1 on create; facets 2/3 on any delport/rmnode with members). On production kernels the same paths take ifnet_mtx and member serializers from netisr context — sleep-in-netisr / lock-order hazards. Trigger requires the netgraph control socket (root on stock DFly), so this is a hard functional break + robustness defect, not an unprivileged primitive.

Fix

Architectural: interface attach/detach/ioctl work must be deferred out of netisr (e.g., queued to a thread) and member ioctls must be wrapped in ifnet_serialize_all/deserialize_all. No single-line fix validated here (the verification used three documented enablers precisely because the correct fix is structural); fix_status: not_testable.

Attempts: 2 (facet 1), 1 (facet 2), 1 (facet 3).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.

(No fix.diff for this item: documented recommendation only - see Fix above.)