Unsynchronized ng_eiface_next_unit++ races under concurrent node creation β duplicate interface unit numbers and duplicate if_xname ifnets
Summary
ng_eiface_next_unit is a plain global int read-modify-written in the constructor with no lock; v1 netgraph processes control messages from netisr context on multiple CPUs (DF-3484), so two concurrent mkpeer eiface operations can both read unit N, produce two ngethN ifnets with identical if_xname, and race ether_ifattach on the global ifnet list - interface/accounting confusion and lookups binding to the wrong instance. Requires concurrent root-driven node creation; masked on stock kernels by DF-3486's constructor panic (the next defect behind it once DF-3486 is fixed). No direct memory corruption demonstrated; state confusion only. Verification skipped (Low, non-memcorrupt/privesc).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3542 Β· 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 639 B | view raw |
Fix verification
not_testableConfirmed kernel references
β
Detail
Evidence (decisive lines)
β
Verdict
Verification deliberately skipped (Low, non-memcorrupt/privesc, masked on stock by DF-3486 which panics node creation first). Audit-trail reasoning recorded: DF-3484 established cross-CPU concurrent processing of the v1 global netgraph queue; ng_eiface_next_unit is a non-atomic RMW in that context. Fix: atomic_fetchadd_int.
No comments yet.