DF-0729 — NULL mbuf dereference in P2P (point-to-point) routing-loop detector

Summary

sys/netinet6/ip6_forward.c:259 — the IFF_POINTOPOINT routing-loop detector in the IPv6 forwarding path — calls icmp6_error(mcopy, ...) without checking if mcopy == NULL. The mcopy comes from m_copym(m, 0, ..., M_NOWAIT) at line 138, which returns NULL under memory pressure (mbuf objcache exhaustion). All four sibling callers in the same function (lines 159, 181, 215, 224) guard NULL; this one does not. icmp6_error() (icmp6.c:264) immediately dereferences m->m_flags (offset 0x1c) — a NULL-page fault → kernel panic.

Severity: Medium (DoS — requires memory pressure precondition)

How to reproduce

Prerequisites

• DragonFlyBSD guest with the unpatched audit-source kernel (#0).
• Root access to load the harness module (for the deterministic proof).

Build

./build.sh    # builds df729_harness.ko + userspace triggers

Run (deterministic harness — PRIMARY PROOF)

./run.sh      # loads module, drains mbufs, triggers icmp6_error(NULL)

Expected on unpatched kernel (#0): kernel panic

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1c
Stopped at icmp6_error+0x54: movl 0x1c(%rbx),%eax

Expected on patched kernel (#1): returns normally, system stays alive.

Live network path (attempted, documented)

See setup.sh for the gif self-tunnel + IPv6 forwarding configuration that exercises the real ip6_forward code path. Under mbuf exhaustion, the network-stack chicken-and-egg problem (the exhaustion prevents the trigger packet from arriving) makes the live trigger probabilistic. The harness provides the deterministic proof.

Files

Fix

1. ip6_forward.c:259: add if (mcopy) guard (matching siblings)
2. icmp6.c:262: add if (m == NULL) return; (defense-in-depth)

DF-0729 — VERDICT

Verdict: REPRODUCED (DoS — NULL-deref kernel panic under memory pressure)

Impact: panic (local/remote DoS). No escalation possible — pure NULL-page read at a fixed address (0x1c), no write primitive, no controlled content.

Confidence: certain.

The Bug

File: sys/netinet6/ip6_forward.c — the IPv6 forwarding path's IFF_POINTOPOINT routing-loop detector (the "P2P" in the title = point-to-point interface, NOT WiFi P2P / 802.11).

At line 138, ip6_forward() makes a copy of the incoming packet for potential ICMPv6 error generation:

mcopy = m_copym(m, 0, imin(m->m_pkthdr.len, ICMPV6_PLD_MAXLEN), M_NOWAIT);

m_copym(M_NOWAIT) calls m_gethdr(M_NOWAIT) which returns NULL when the mbuf objcache (mbufphdr_cache, 146632 slots) is exhausted — i.e. under memory pressure (DDoS flood, sustained high packet rate).

Four sibling callers in the same function guard NULL: - Line 159: if (mcopy) { icmp6_error(mcopy, ...); } - Line 181: if (mcopy) { icmp6_error(mcopy, ...); } - Line 215: if (mcopy) icmp6_error(mcopy, ...); - Line 224: if (mcopy) { ... icmp6_error(mcopy, ...); }

Line 259 does NOT guard NULL — the P2P loop detector path:

if (rt->rt_ifp->if_flags & IFF_POINTOPOINT) {
    /* ... routing loop detected ... */
    icmp6_error(mcopy, ICMP6_DST_UNREACH,         // line 259 — BUG
                ICMP6_DST_UNREACH_ADDR, 0);
    m_freem(m);
    return;
}

icmp6_error() (sys/netinet6/icmp6.c:250) has no NULL check — its first field dereference at line 264 reads m->m_flags (offset 0x1c in struct mbuf), which is a NULL-page address when m == NULL:

void icmp6_error(struct mbuf *m, int type, int code, int param)
{
    ...
    if (m->m_flags & M_DECRYPTED) {   // line 264 — NULL deref at 0x1c

Result: Fatal trap 12: page fault at 0x1c — Stopped at icmp6_error+0x54

Trigger Conditions (realistic — hence Medium severity)

1. IPv6 router (net.inet6.ip6.forwarding=1) — realistic deployment.
2. Point-to-point interface with a routing loop (egress==ingress): gif/gre/ ppp/stf tunnel misconfiguration where the routed prefix loops back through the same tunnel interface. rcvif == rt_ifp AND IFF_POINTOPOINT.
3. Memory pressure — mbuf objcache exhausted (DDoS flood, sustained high packet rate). This makes m_copym(M_NOWAIT) return NULL.
4. An IPv6 packet arrives on the P2P interface destined for the looped prefix.

The conjunction of all four is the realistic-but-probabilistic trigger that justifies Medium rather than High severity.

Reproduction

Deterministic kernel-module harness (PRIMARY PROOF)

Since the live network trigger requires a narrow timing window (mbuf exhaustion must coincide with an arriving forwarded packet — the classic chicken-and-egg of memory-pressure bugs), a deterministic kernel-module harness provides definitive proof.

df729_harness.ko (sysctl handler): 1. Drains the mbuf pool by allocating and holding 150000 mbufs via m_gethdr(M_NOWAIT) — proves the objcache exhaustion condition. 2. Calls icmp6_error(NULL, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_ADDR, 0) — exactly as ip6_forward.c:259 does when mcopy == NULL.

Baseline (#0 unpatched) result — PANIC:

DF729: holding 150000 mbufs. m_copym(M_NOWAIT) will now fail.
DF729: simulating ip6_forward.c:259 — icmp6_error(NULL, DST_UNREACH, ADDR, 0)
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x1c
Stopped at      icmp6_error+0x54:       movl    0x1c(%rbx),%eax

mbuf exhaustion proof (userspace flood)

A userspace UDP flood (64 threads × 200 socket pairs) successfully exhausted the mbuf pool, confirmed in the serial log:

Warning: objcache(mbuf pkthdr) exhausted on cpu1!
Warning: objcache(mbuf pkthdr) exhausted on cpu2!
Warning: objcache(mbuf pkthdr) exhausted on cpu3!
Warning: objcache(mbuf pkthdr) exhausted on cpu4!
Warning: objcache(mbuf pkthdr) exhausted on cpu5!

This proves m_gethdr(M_NOWAIT) (called by m_copym) genuinely fails under realistic memory pressure — the precondition for the bug.

Live network path (attempted)

A gif self-tunnel (10.0.2.15 → 10.0.2.15) with IPv6 forwarding and a route for fc00:dead::/64 through gif0 was configured to reproduce the real code path. Under mbuf exhaustion, the trigger packets failed with EADDRNOTAVAIL — the network stack itself couldn't allocate mbufs for the send path, preventing packets from reaching ip6_forward. This is the fundamental chicken-and-egg problem of memory-pressure-triggered bugs: the exhaustion that causes m_copym to fail also prevents the trigger packet from arriving. The deterministic harness resolves this by separating the drain (creating pressure) from the trigger (calling the vulnerable function directly).

Exploit Chain

Not applicable. This is a NULL-deref DoS — a read from address 0x1c (the m_flags field offset in struct mbuf). There is: - No write primitive (read fault, not write) - No controlled content (the NULL pointer comes from m_copym failure, not attacker data) - No pivot possibility (fixed small address in the NULL page)

The impact ceiling is kernel panic / DoS — no escalation to uid=0 is derivable from this primitive.

PoC Changes

• df729_harness.c + Makefile — deterministic kernel-module harness that drains the mbuf pool then calls icmp6_error(NULL,...), reproducing the exact unchecked code path from ip6_forward.c:259.
• df729_trigger.c — userspace mbuf-exhaustion flood (64 threads × 200 socket pairs) that proved m_gethdr(M_NOWAIT) fails under pressure.
• df729_udp_trigger.c — network-path trigger (UDP packets to the gif routing loop target); did not trigger due to the chicken-and-egg mbuf problem.
• setup.sh — configures gif self-tunnel + IPv6 forwarding + route for the live-network-path attempt.
• fix.diff — the fix (see below).

Recommended Fix

Two changes (defense in depth):

1. Primary — sys/netinet6/ip6_forward.c:259: add if (mcopy) guard before the icmp6_error call, matching the 4 sibling callers at lines 159, 181, 215, 224.

2. Defense-in-depth — sys/netinet6/icmp6.c:262: add if (m == NULL) return; at the top of icmp6_error, protecting ALL callers from NULL mbuf.

fix.diff — applies cleanly, builds, and validates:

Baseline (#0): harness → PANIC (icmp6_error+0x54, fault at 0x1c) Patched (#1): same harness → SURVIVED (icmp6_error(NULL) returns normally via the NULL guard, system stays up, mbufs released cleanly)

The full git apply-able diff is in fix.diff.