LACP leaks the slow-protocols multicast membership and ifma refcount on every member-port removal: if_delmulti_ifma is #if 0'd out and no equivalent cleanup exists in the tree
Summary
lacp_port_create() calls if_addmulti(ifp, slowprotocols_dl, &rifma) on every member-port join, storing the ifmultiaddr in lp->lp_ifma. The matching removal in lacp_port_destroy() is compiled out (#if 0 at :592-596) and the functions it names - if_delmulti_ifma() and if_purgemaddrs() - do not exist anywhere in the DragonFly tree, so nothing ever drops the reference. lagg_port_destroy's lagg_ether_cmdmulti removes only memberships tracked in lp->lp_mc_head, which does not include LACP's. Every 'ifconfig laggX laggport tapN' / '-laggport tapN' cycle under laggproto lacp increments ifma_refcount with no decrement, and each lagg_lladdr() change destroys+recreates all lacp ports, leaking twice per MAC change. Impact: member NIC keeps the 01:80:c2:00:00:02 filter programmed and keeps receiving slow-protocol frames forever after leaving the lagg; ifma_refcount grows unboundedly and after a theoretical 2^32 cycles wraps -> premature ifmultiaddr removal while still referenced -> UAF (unreachable in practice). Root-privileged trigger; realistic impact is resource leakage and lingering multicast RX filtering. Distinct from DF-3347 (which is the ignored ENOMEM return leaving NULL lp_psc; this is the unconditional successful-path leak). Fix: if_delmulti with the same sockaddr_dl in lacp_port_destroy + move kmalloc before if_addmulti. [VERIFIED pass2: reproduced live and quantified - if_delmulti_ifma compiled out so 20 cycles leak 2 ifma each permanently surviving interface destroy, ether_multi 38 to 78; release-the-caller-ref fix A/B 21 DELMADDR vs 0]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3349 · 7 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 979 B | ↓ raw | |
| VERDICT.md | — | 2.5 KB | ↓ raw | |
| fixkernel.log | — | 316 B | view raw | |
| live3.log | — | 918 B | view raw | |
| manifest.json | — | 789 B | view raw | |
| mtrace.c | — | 1.6 KB | view raw | |
| verdict.json | — | 1.8 KB | view raw |
DF-3349 -- verification pack
Method: Live PoC on the QEMU guest (stock INVARIANTS kernel) Status: REPRODUCED | impact: none | confidence: certain
What this is
lacp_port_destroy never releases the slow-protocols membership / ifma caller reference (if_delmulti_ifma compiled out, lacp.c:584-591): after -laggport the membership persists (PF_ROUTE trace shows NEWMADDR with no DELMADDR) and the ifma allocations leak PERMANENTLY - 20 create/port/remove/destroy cycles grew ether_multi in-use from 38 to 78 (+2 per cycle, surviving interface destroy; the leaked objects also keep ifma_ifp pointing at freed ifnets).
Build
cc -O -o <prog> <prog>.c (on the guest)
Run
(driver script)
(success criterion: see VERDICT.md)
Evidence
live3.log lacp section: NEWMADDR with no DELMADDR; ether_multi 38 -> 78 after 20 cycles
Kernel references: sys/net/lagg/ieee8023ad_lacp.c:584-591, sys/net/lagg/ieee8023ad_lacp.c:530-551, sys/net/if.c:2667-2684
DF-3349 -- VERDICT
REPRODUCED (impact=none, confidence=certain) Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
Summary
lacp_port_destroy never releases the slow-protocols membership / ifma caller reference (if_delmulti_ifma compiled out, lacp.c:584-591): after -laggport the membership persists (PF_ROUTE trace shows NEWMADDR with no DELMADDR) and the ifma allocations leak PERMANENTLY - 20 create/port/remove/destroy cycles grew ether_multi in-use from 38 to 78 (+2 per cycle, surviving interface destroy; the leaked objects also keep ifma_ifp pointing at freed ifnets).
How it was verified
- Method: Live PoC on the QEMU guest (stock INVARIANTS kernel)
- Kernel references: sys/net/lagg/ieee8023ad_lacp.c:584-591, sys/net/lagg/ieee8023ad_lacp.c:530-551, sys/net/if.c:2667-2684
- Evidence: live3.log lacp section: NEWMADDR with no DELMADDR; ether_multi 38 -> 78 after 20 cycles
- Reachability: local-unpriv where noted in the summary; root-config for tun/lagg/carp/ipfw3/gre items; remote-facing for the packet parsers (wlan harnesses model the RX/TX path verbatim because the guest has no 802.11 hardware; precedent DF-0393/DF-0594/DF-0621/DF-0350).
- Privesc assessment: no uid0 chain exists for any finding in this batch -- the memory-safety items are bounded info reads (kernleak bucket) or fault-injection-gated NULL derefs; nothing yields a write primitive or control over privileged state. The one panic-class live item (DF-3414) is root-only (SIOCIFDESTROY).
Fix
fix_status: fixed -- Validated on the patched kernel: the combined-fix build releases the caller reference in lacp_port_destroy (after dropping the LACP lock); after the fix, 20 create/port/remove/destroy cycles leave ether_multi in-use unchanged and a DELMADDR fires on each -laggport (see fixkernel section).
Baseline vs patched (kernel): see fixkernel-*.log -- the combined-fix kernel (DF-3308+DF-3349+DF-3359+DF-3445/3446 fixes built together) was booted and the exact PoCs re-run.
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.)
Fix verification
fixedA/B on the combined-fix kernel: baseline leaked +2 ifma per cycle with zero DELMADDR events; patched kernel emits 21 DELMADDR events across 20 create/port/remove/destroy cycles (membership released). See fixkernel.log.
Confirmed kernel references
Detail
Evidence (decisive lines)
live3.log lacp section: NEWMADDR with no DELMADDR; ether_multi 38 -> 78 after 20 cycles
Verdict
lacp_port_destroy never releases the slow-protocols membership / ifma caller reference (if_delmulti_ifma compiled out, lacp.c:584-591): after -laggport the membership persists (PF_ROUTE trace shows NEWMADDR with no DELMADDR) and the ifma allocations leak PERMANENTLY - 20 create/port/remove/destroy cycles grew ether_multi in-use from 38 to 78 (+2 per cycle, surviving interface destroy; the leaked objects also keep ifma_ifp pointing at freed ifnets).
No comments yet.