DF-3358 — Unprivileged permanent rtmask-table pollution via RTM_GET + RTA_GENMASK

• File: sys/net/rtsock.c (route_output, lines ~738-748)
• Class: unprivileged kernel resource exhaustion / permanent memory consumption (local DoS)
• Bucket: base:net

Prerequisites

• local unprivileged user account (no privilege, no jail escape, nothing)
• DragonFly default kernel — verified on DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (INVARIANTS stock)

Build

cc -O2 -Wall -o rtmask_poc rtmask_poc.c        # on the guest, base gcc

Run

# baseline (root):
vmstat -m | grep routetbl
# exploit (unprivileged):
/tmp/rtmask_poc 100000                 # unique genmask per RTM_GET
vmstat -m | grep routetbl              # +~586K allocs, +73MB, permanent
# control (unprivileged):
/tmp/rtmask_poc 20000 same             # same mask repeated -> ZERO growth

Expected result

Every RTM_GET message carrying a previously-unseen RTA_GENMASK sockaddr makes the kernel permanently allocate RN_MAXKEYLEN + 2*sizeof(struct radix_node) = 128 bytes per CPU (guest has 6 CPUs → 768 B/message) in the M_RTABLE ("routetbl") pool. The mask trees never shrink and the key space is attacker-chosen.

Measured on the guest (uid 1001 maxx):

After exhaustion the system-wide routing plane is bricked until reboot: route add fails ("routing table overflow") even for root, getifaddrs fails inside route(8), and the kernel logs arpresolve: can't allocate llinfo for any new neighbor.

Fix

fix.diff — require SYSCAP_RESTRICTEDROOT when an RTM_GET carries a genmask (root semantics unchanged; plain unpriv RTM_GET unchanged).

Files

• rtmask_poc.c — PoC source
• build.sh, run.sh — exact commands
• build.log — compiler output
• run.log — 100k unique run + routetbl before/after
• run.2.log — 600k run hitting the 390M malloc-type limit (ENOBUFS @ 532,426)
• run.3.log — post-exhaustion impact probe (route add fails as root, arpresolve failures)
• env.baseline.txt — guest uname + baseline vmstat
• fix.diff — the fix (validated: see VERDICT.md)
• VERDICT.md, manifest.json, verdict.json

DF-3358 — VERDICT

Finding: route_output() in sys/net/rtsock.c installs routing genmasks globally (rtmask_add_global()) for every message type, including RTM_GET — the single message type unprivileged users may send (the privilege check at sys/net/rtsock.c:738-740 explicitly skips RTM_GET; the genmask block at :742-748 runs before the type switch and is therefore not covered by that check).

Root cause chain (all line-cited against this tree): 1. sys/net/rtsock.c:738-740 — privilege gate exempts RTM_GET. 2. sys/net/rtsock.c:742-748 — if (rtinfo.rti_genmask != NULL) rtmask_add_global(...) runs for all types, incl. RTM_GET. The author even picked a lower message priority for GETs (RTREQ_PRIO_NORM) — aware unpriv users send GETs — but never gated the install itself. 3. sys/net/route.c:1762-1806 — rtmask_add_global forwards to every CPU; rtmask_add_msghandler calls rtmask_lookup() = _rtmask_lookup(mask, FALSE). 4. sys/net/route.c:1776-1792 + sys/net/radix.c:587-599 — _rtmask_lookup with search=false → rn_addmask(..., false, ...) which, for a mask pattern not already in the per-CPU mask tree, kmallocs RN_MAXKEYLEN + 2*sizeof(struct radix_node) (= 32 + 2×48 = 128 bytes) and inserts it. Mask-tree nodes have no free path (nothing in route.c/radix.c ever removes them; only route nodes are freed, not mask-tree entries). 5. The mask key is 32 attacker-chosen bytes (trailing-zero-trimmed), so the number of distinct installs is effectively unbounded (2^248 patterns).

Reachability: any local user. socket(PF_ROUTE, SOCK_RAW, 0) is unprivileged (routing monitors use it); write() of an RTM_GET message with RTA_DST|RTA_GENMASK triggers the install. The message does not even need to match a route — the genmask is installed before the lookup (ESRCH is returned after the memory is consumed).

Reproduced on the single-tenant QEMU guest (DragonFly dfbsd 6.5-DEVELOPMENT #0 ... X86_64_GENERIC, 6 CPUs, stock INVARIANTS kernel), as uid 1001 maxx:

• Baseline vmstat -m | grep routetbl: Count 234, MemUse 38.0K.
• 100,000 RTM_GETs with unique genmasks (9.2 s wall): Count 586K, MemUse 73.3M — ≈ 5.86 allocations/message = one per CPU (6), 128 B each. (run.log)
• Control: 20,000 RTM_GETs repeating ONE mask → zero growth (Count 586K unchanged) — proves the unique-pattern insert path is what allocates.
• Ceiling: continued to the M_RTABLE malloc-type limit — ENOBUFS at iteration 532,426 with Count 3.05M, MemUse 390M/390M (run.2.log).
• Post-exhaustion impact (run.3.log): route add fails ("routing table overflow") as root; route(8)'s getifaddrs probe fails ("Cannot allocate memory"); kernel logs repeated arpresolve: can't allocate llinfo for any new neighbor. Existing cached traffic keeps working. Nothing frees the 390M — reboot is the only recovery.

Total cost to brick the routing plane: ~60 s of unprivileged userspace.

Not a panic/corruption primitive: allocations are in-bounds and correctly freed-free (they are simply never supposed to be freed); this is a pure unbounded permanent-consumption DoS, so the escalation question (uid=0) does not arise. Verdict: reproduced, impact dos, confidence certain.

Fix (fix.diff): require SYSCAP_RESTRICTEDROOT when an RTM_GET carries a genmask, right after the existing privilege check. Root semantics unchanged; unprivileged plain RTM_GET (no genmask) unchanged.

Fix validation (performed on the guest, same run — fix.run.log): vm.sh reset with-src → applied fix.diff to the guest's /usr/src/sys/net/rtsock.c (patch: Hunk #1 succeeded at 739) → make -j6 nativekernel + make installkernel → rebooted into the patched kernel (#1: Fri Sep 11 09:08:32, see env.txt) → re-ran the exact PoC as uid 1001: - Baseline routetbl on patched kernel: 234 / 38.0K. - 100,000 unique-genmask RTM_GETs: EPERM at iteration 0 (PoC exits as designed on the unexpected error); routetbl Count unchanged (234 / 38.0K, Requests 283→284) — no allocation occurs. - Positive control as root (10,000 unique-genmask GETs): Count 234 → 58.8K, MemUse → 7.36M (≈6 allocs/cpu/message) — the privileged install path is fully preserved. - Positive control as uid 1001: plain RTM_GET without genmask (rtget_plain.c) → write=168 errno=0, not EPERM — unprivileged route(8)-style RTM_GET monitors keep working.

fix_status: fixed — bad behavior gone on the patched kernel, root behavior and unpriv plain-GET behavior preserved.

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.