DF-3514 — ng_ID_rehash/ng_name_rehash: entries not unlinked (non-INVARIANTS) + wrong destroy mask -> kernel panic

What

sys/netgraph7/netgraph/ng_base.c:

• ng_ID_rehash() (lines 973-999): the migration loop unlinks nodes from the old ID-hash only under #ifdef INVARIANTS (lines 988-990). On production (non-INVARIANTS) kernels — and in any standalone KLD module build, which does not inherit the kernel's INVARIANTS flag — every node stays linked into the OLD table and is additionally inserted into the new one. hashdestroy() on the still-populated old table then panics ("hashdestroy: hash not empty"). Independently, line 996 passes the WRONG mask: hashdestroy(ng_ID_hash, M_NETGRAPH_NODE, ng_name_hmask) — the name-hash mask instead of ng_ID_hmask; if the name hash is smaller than the ID hash the walk under-runs, if larger it walks OOB past the old table.
• ng_name_rehash() (lines 941-967): same INVARIANTS-only LIST_REMOVE (lines 956-958); destroy mask is correct here but the un-migrated old table still triggers the same panic.

Double-insertion is also a list-corruption UAF: when such a node is later freed via one list, the other list keeps a dangling pointer.

Reachability

Rehash fires when ng_nodes * 2 > ng_ID_hmask (8 live/leaked nodes for the initial 16-bucket table) at ng_make_node_common() (line 657-658), and when named nodes cross the equivalent threshold in ng_name_node(). Node counts inflate permanently via the reference leaks in DF-3513 (drained conq items pin their el_dest node) and DF-3515 (callout items pin their node while armed/stopped) — so routine bluetooth traffic or any repeated graph build/teardown eventually crosses the threshold; the NEXT node creation (its caller can be any subsystem creating a netgraph node, e.g. a socket) panics the kernel.

Reproduced

4 panics on the QEMU guest (3x via ng_make_node_common during ngc_attach, 1x via ng_name_node after only the ID-rehash half was fixed), all "hashdestroy: hash not empty". Traces in panic.txt. Fix (unconditional LIST_REMOVE + correct mask, both functions) validated at module level: after the fixed core module was loaded, 20 consecutive DF-3513 PoC cycles (each previously sufficient to cross the threshold and panic) completed with exit 0 and no panic.

Reproduce (same harness as DF-3513)

build+load ng7 modules (unfixed), then repeatedly: ./poc_leak 500 (each run pins nodes via the leaks). Panic occurs within ~3-8 runs. With the fixed core module: 20/20 runs survive.

DF-3514 — VERDICT

Status: reproduced (impact: panic). Fix validated (module-level).

Reproduced 4x on the guest, all panic: hashdestroy: hash not empty: * 3x ng_make_node_common() path (ID-hash rehash at node creation), * 1x ng_name_node() path (name-hash rehash — same bug class; first appeared after the ID-half fix, confirming both halves are live).

Root cause certain from source + traces: #ifdef INVARIANTS-gated LIST_REMOVE in the rehash migration loops (ng_base.c:956-958, 988-990) leaves every entry double-inserted on production/standalone-module builds; hashdestroy() then trips. Additionally ng_ID_rehash() destroys the old ID table with ng_name_hmask (ng_base.c:996) — wrong mask (OOB/under-run walk).

Driver for crossing the rehash threshold in practice: permanent node-ref inflation from DF-3513 (drained conq items pin el_dest) and DF-3515 (callout items pin their node) — both reproduced in the same session; also plain repeated named-graph build/teardown.

Fix validated: unconditional LIST_REMOVE in both rehash functions + hashdestroy(ng_ID_hash, M_NETGRAPH_NODE, ng_ID_hmask). Guest module rebuild; the previously-panicking workload (20 PoC cycles) then survived 20/20 with exit 0.

Classification: status=reproduced, reproduced=1, impact=panic, confidence=certain, fix_status=fixed.

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.