DF-0752 — mbuf leak in mpls_forward on route-not-found

Claim

mpls_forward() in sys/netproto/mpls/mpls_input.c leaks the input mbuf on the route-not-found path: when rtalloc(cache_rt) leaves cache_rt->ro_rt == NULL, the function returns at line 202 without calling m_freem(m) (and without bumping mplss_cantforward). Every other drop path in this file frees the mbuf (lines 156, 164, 170, 218). An on-link remote attacker who can deliver MPLS-framed Ethernet packets (ethertype 0x8847) with a label that has no matching MPLS route causes one mbuf+cluster leak per packet → memory-exhaustion DoS. Requires options MPLS in the kernel config (non-default; the X86_64_GENERIC shipped kernel does NOT compile MPLS in).

Reproduce

The bug is unreachable on default GENERIC (MPLS not compiled in). The harness here therefore uses a kernel built with options MPLS (the documented precondition of the finding) and delivers MPLS frames into the kernel via a tap(4) interface from a root-run injector (simulating the on-link attacker).

1. ./build.sh — build the injector (mpls_flood)
2. On an options MPLS kernel: sudo ifconfig tap0 create; sudo ifconfig tap0 up
3. sudo ./run.sh — flood 20000 unroutable-label MPLS frames into tap0, printing netstat -m mbuf counts before/after.

Expected on the UNPATCHED MPLS kernel: mbufs-in-use grows by ~20000 (leak). Expected on the FIXED kernel: mbufs-in-use stays flat (m_freem now called).

Files

• mpls_flood.c — injector: writes N MPLS frames (label=1000, no route) to /dev/tap0
• build.sh / run.sh — exact build/run
• fix.diff — adds m_freem(m); mplsstat.mplss_cantforward++; before return;
• VERDICT.md — full narrative
• manifest.json — artifact catalog

DF-0752 — VERDICT

Verdict

REPRODUCED — mbuf leak in mpls_forward() on the route-not-found path is real and confirmed live on a kernel built with options MPLS. The fix (m_freem(m); mplsstat.mplss_cantforward++; before the return;) is VALIDATED by a built-and-booted single-fix kernel: the same flood that leaks exactly +1 mbuf/packet on the unpatched kernel leaks ZERO mbufs on the fixed kernel across 100000 packets.

The bug (mechanism, with path:line)

sys/netproto/mpls/mpls_input.c, function mpls_forward() (lines 173–219):

173: static void
174: mpls_forward(struct mbuf *m)
...
191:     if (cache_rt->ro_rt == NULL || smpls->smpls_label != label) {
...
199:         rtalloc(cache_rt);
200:         if (cache_rt->ro_rt == NULL) {
201:             /* route not found */
202:             return;          // <-- BUG: m is leaked; no m_freem(m)
203:         }
204:     }

When the MPLS forwarding route cache has no entry (or the cached route is for a different label) and rtalloc() fails to find a route for the label (cache_rt->ro_rt == NULL), the function returns at line 202 without calling m_freem(m). The mbuf passed in by the caller is orphaned — its storage is never returned to the mbuf pool. The mplss_cantforward stat is also never bumped (the finding notes this; the fix adds it for parity with the mplsforwarding=0 branch).

This is the only drop path in the file that fails to free m. Every sibling error/drop path calls m_freem(m): - mpls_input() reserved-label path: mpls_input.c:156 m_freem(m); return; - mpls_input() mplsforwarding=0 branch: mpls_input.c:163-165 mplsstat.mplss_cantforward++; m_freem(m); return; ← the template for our fix - mpls_input() end-of-switch invalid label: mpls_input.c:169-170 mplsstat.mplss_invalid++; m_freem(m); - mpls_forward() bad: label (output error): mpls_input.c:217-218 m_freem(m);

The route-not-found return at 202 is the lone exception — an oversight.

Reachability

The path is reached for every MPLS frame whose label has no matching MPLS route, when MPLS forwarding is enabled. Control flow:

1. An Ethernet frame with ethertype ETHERTYPE_MPLS (0x8847) is received. ether_demux() (sys/net/if_ethersubr.c:1618-1624, #ifdef MPLS) sets M_MPLSLABELED and routes it to NETISR_MPLS.
2. mpls_input_handler() → mpls_input() (mpls_input.c:76-85, 87-171). For labels > 15 (not reserved) with mplsforwarding != 0 (default = 1, mpls_input.c:51), it calls mpls_forward(m) and returns (mpls_input.c:159-161).
3. mpls_forward() does rtalloc(cache_rt) for the label (mpls_input.c:199). If no MPLS route exists → leak at return; (202).

options MPLS is required — it is NOT in the shipped X86_64_GENERIC config (sys/config/X86_64_GENERIC has no options MPLS; the four netproto/mpls/*.c files are optional mpls in sys/conf/files). So on the default GENERIC kernel the bug is unreachable (no MPLS code compiled in, no MPLS demux in ether_input). The finding's Medium severity and its stated precondition ("MPLS forwarding must be enabled") reflect this: the bug is real and exploitable on any deployment that opts into MPLS, but cannot be triggered against a stock GENERIC box.

Reproduction (live, on an options MPLS kernel)

To make the path reachable I built X86_64_GENERIC with options MPLS added (the documented precondition of the finding), booted it, and delivered MPLS frames into the kernel via a tap(4) interface from a root-run injector (mpls_flood.c) that simulates the on-link attacker who can put arbitrary Ethernet frames on the wire. The MPLS route table was left empty so every non-reserved label hits the route-not-found path.

Unpatched MPLS kernel (6.5-DEVELOPMENT #1 built 2026-07-09 09:03, sha256 b31400ab…):

1000-frame flood :  mbufs in use  7   -> 1007   (delta +1000, exactly 1/packet)
20000-frame flood:  mbufs in use  1009-> 21007  (delta +20000, exactly 1/packet)

The mbuf pool cap is 146632, so ~7 floods of 20000 frames exhaust it. This is the remote memory-exhaustion DoS the finding describes.

Exploit chain / escalation

None. This is a pure resource-exhaustion (mbuf leak) primitive — no memory corruption, no type confusion, no write primitive. Each leaked mbuf is an orphaned allocation that is never freed; the attacker cannot read or shape its contents. The realistic impact ceiling is denial of service: sustained flooding exhausts the mbuf pool and network processing stalls for all users. There is no path to uid=0 from a pure leak. (Characterized and moved to fix.)

Fix

fix.diff adds the two lines that close the path, mirroring the mplsforwarding=0 sibling at lines 162–166 exactly:

--- a/sys/netproto/mpls/mpls_input.c
+++ b/sys/netproto/mpls/mpls_input.c
@@ -199,6 +199,8 @@
        rtalloc(cache_rt);
        if (cache_rt->ro_rt == NULL) {
            /* route not found */
+           mplsstat.mplss_cantforward++;
+           m_freem(m);
            return;
        }

m_freem(m) returns the mbuf to the pool; the mplss_cantforward++ brings the stat into line with the other "cannot forward" drop paths so the leak becomes observable in netstat-style counters.

Fix validation (Phase 8) — single-fix kernel built, booted, and tested

Applied only fix.diff to mpls_input.c (MPLS config retained so the path stays reachable), rebuilt with make -j6 nativekernel KERNCONF=X86_64_GENERIC (warm obj), installed /boot/kernel/kernel from the freshly-built kernel.stripped (sha256 8d5bb36d…, verified byte-for-byte), rebooted.

Fixed MPLS kernel (6.5-DEVELOPMENT #1 built 2026-07-09 09:31):

20000-frame flood :  mbufs in use  8 -> 7   (delta -1, noise; NO leak)
40000-frame flood :  mbufs in use  8 -> 7   (delta -1, noise; NO leak)
40000-frame flood :  mbufs in use  7 -> 7   (delta  0; NO leak)
                                                       (100000 frames total, zero growth)

The before/after contrast is unambiguous: the unpatched kernel leaks exactly 1 mbuf/packet (20000 → +20000), the fixed kernel leaks 0 across 100000 packets. fix_status: fixed.

Caveats

• Default GENERIC is not affected (MPLS not compiled in). The leak is reachable only on kernels built with options MPLS. This matches the finding's stated precondition and its Medium severity.
• The fix kernel was built with options MPLS added to X86_64_GENERIC (necessary for reachability); the only source diff between the unpatched baseline kernel and the fixed kernel is fix.diff (2 lines in mpls_input.c), isolating the fix as the variable.

Files in this evidence pack