DF-0418 — Unbounded default-router/prefix list growth from RA flood

Verdict: REPRODUCED (DoS) + FIX VALIDATED

Summary

defrtrlist_update() (sys/netinet6/nd6_rtr.c:689) kmallocs a fresh struct nd_defrouter for every unique RA source link-local address and TAILQ_INSERT_TAILs it with no upper bound. nd6_prelist_add() (nd6_rtr.c:765) does the same per unique prefix, and pfxrtr_add() (:727) per prefix-router pair. The only cap in the tree, nd6_maxndopt (nd6.c:128), limits the number of ND options per packet, not cross-packet accumulation. An on-link unauthenticated attacker who floods RAs with a fresh randomized source + prefix each causes unbounded M_IP6NDP kmalloc → kernel memory exhaustion → system hang/panic. This is the classic RFC 6104/6105 RA-flooding DoS.

Reachability (the realistic precondition)

nd6_ra_input() (nd6_rtr.c:200) accepts an RA only when !ip6_forwarding && (ND_IFINFO(ifp)->flags & ND6_IFF_ACCEPT_RTADV) (:221). ND6_IFF_ACCEPT_RTADV is set per-interface at init from the global net.inet6.ip6.accept_rtadv (nd6.c:210), which is 0 by default. So on a default DragonFly install RAs are NOT processed; the bug is reachable only on a host that has enabled SLAAC (accept_rtadv=1) — a common, realistic configuration for any IPv6 autoconfig host. The CVSS AV:A (adjacent) vector is correct: the attacker must be on-link.

Reproduction (baseline #0 unpatched kernel)

Forged RAs are injected as ingress on a tap0 interface (writing raw Ethernet+IPv6+ICMPv6 RA frames to /dev/tap0 delivers them to the kernel RX path, exercising nd6_ra_input exactly as a real on-link RA would). Each RA carries a unique fe80:: source and a unique 2001:db8:<i>::/64 prefix.

precondition: net.inet6.ip6.accept_rtadv=1 + ND6_IFF_ACCEPT_RTADV on tap0
before: ndp=6 entries, free pages=833542
flood 2000 RAs (unique src + prefix each)
after:  ndp=4006 entries, free pages=832973 (-~2.3MB for 2k RAs)
        M_IP6NDP slab = 485K current, 390M cumulative, ~tens of thousands of allocs

Memory scales linearly with #unique RAs; an attacker trivially exhausts GBs. At ~4200 cumulative RAs the slab showed 969K current / 390M cumulative and free pages had dropped ~10MB. This is an unbounded-growth DoS.

Exploit chain

Not memory corruption (no primitive derivable) — this is a resource-exhaustion DoS. No uid=0 chain applies. Realistic impact ceiling: permanent kernel memory exhaustion / OOM-kill / hang on any SLAAC (accept_rtadv=1) host from an on-link attacker; no privilege gain.

Recommended fix (validated)

fix.diff adds two per-interface caps, nd6_maxdefrouters and nd6_maxprefixes (default 16 each — generous for legitimate multi-router/ multi-prefix deployments, RFC 4191), enforced by counting same-ifp entries in defrtrlist_update and nd6_prelist_add before the kmalloc. Over-cap entries are refused and logged. The caps could be promoted to sysctls (trivial) but are plain globals matching the existing nd6_maxndopt style.

Fix validation (single-fix kernel #1, built + booted)

baseline #0  : 2000 RAs -> tap0 grew to ~thousands of autoconf addrs,
               M_IP6NDP slab = 485K-969K current, thousands of allocs
patched #1   : 2000 RAs -> tap0 inet6 addrs = EXACTLY 16 (capped),
               M_IP6NDP slab = 6.8K / 68 allocs

The default-router/prefix kmalloc growth is bounded by the fix. (The remaining ~2000 neighbor-cache entries from 2000 distinct source MACs are a separate neighbor-discovery-cache resource, not the router/prefix lists this finding claims — out of scope here.)

Files

• raflood.c — RA-flood PoC: enables ND6_IFF_ACCEPT_RTADV, injects forged RAs via /dev/tap0
• fix.diff — per-interface caps (nd6.c globals + nd6_rtr.c checks + nd6.h externs)
• run.log — baseline reproduction (ndp 6->4006)
• fix_build.log — full single-fix kernel build output (rc=0)
• fix_run.log — patched-kernel run (capped at 16)
• env.txt — guest environment