# DF-2541 — ip_mroute X_ipip_input / pim_input race (NULL-deref / panic)

## Verdict: REPRODUCED (panic); fix_status = fix_failed (minimal token fix insufficient)

## What the finding claimed
`X_ipip_input` (sys/net/ip_mroute/ip_mroute.c:1710) and the PIM-REGISTER branch of
`pim_input` (:3020) read `viftable`/`numvifs`/`last_encap_vif`/`reg_vif_num` **without**
holding `mroute_token`, while `del_vif` (:873) and `X_ip_mrouter_done` (:605) mutate exactly
those fields **under** `mroute_token` (including `bzero()` of `viftable` slots at :909 and
:634). A concurrent teardown can therefore zero a vif between validation and use.

## Reachability established on this guest (6.5-DEVELOPMENT #0, X86_64_GENERIC)
1. **`pim_input` is DEAD CODE here.** It is entirely inside `#ifdef PIM`
   (sys/net/ip_mroute/ip_mroute.c:3250 `#endif /* PIM */`). The GENERIC kernel has no
   `options PIM` (sys/config/X86_64_GENERIC), and the **`ip_mroute.ko` module Makefile
   defines only `-DMROUTING`, not `-DPIM`** (sys/net/ip_mroute/Makefile). Confirmed at
   runtime: `sysctl net.inet.pim` ⇒ *unknown oid*; `nm /boot/kernel/kernel | grep pim_input`
   ⇒ empty. The PIM-REGISTER NULL-deref at :3230 is unreachable on this guest.
2. **`X_ipip_input` is reachable** via the `encap4_input()` backward-compat hook
   (sys/netinet/ip_encap.c:231 `if (proto == IPPROTO_IPV4 && ipip_input)`) once the module
   is `kldload`'d (MOD_LOAD sets `ipip_input = X_ipip_input`, :3266). But its first guard
   (:1716 `if (!have_encap_tunnel)`) returns early unless **root has added a `VIFF_TUNNEL`
   vif** (set in `add_vif` :785-786). `MRT_INIT` requires `SOCK_RAW`/`IPPROTO_IGMP` and
   root (`ip_mrouter_init` :571-572). So this is a **root-configured** race — the realistic
   threat is an admin running mrouted while an attacker floods during MRT_DONE/restart.

## Reproduction (root-configured race → panic)
`poc.c` (run as root): opens the IGMP mrouter socket, `MRT_INIT`, adds a `VIFF_TUNNEL`
vif (rmt=10.0.2.99) → `have_encap_tunnel=1`, primes the `last_encap_vif` cache by flooding
IP-in-IP packets (outer proto=4, inner dst=multicast), then races `MRT_DEL_VIF(0)`+re-add
against the packet flood. del_vif `bzero()`s `viftable[0]` (v_ifp→0) while a packet reuses
the stale cached `last_encap_vif`; the decapsulated multicast packet is then forwarded into
torn-down state.

**Observed (unpatched #0, twice):** `Fatal trap 12: page fault while in kernel mode`,
`instruction pointer = 0x8:0x0` (NULL function-pointer call), `current process = Idle`
(netisr context). Reproducible in <2 s of the race loop. See `panic.txt`, `run.log`,
`run.2.log`.

## Mechanism (cited hops)
- `X_ipip_input` :1734-1747 — walks `viftable`/`numvifs` and caches `last_encap_src`/`
  `last_encap_vif` **with no token**.
- `del_vif` :883 acquires `mroute_token`; :888-891 resets the cache (only if
  `vifp == last_encap_vif`); :909 `bzero((caddr_t)vifp, sizeof(*vifp))` → `v_ifp` = 0.
- `X_ipip_input` :1763 `m->m_pkthdr.rcvif = last_encap_vif->v_ifp;` (stale cache ⇒ NULL),
  :1765 `netisr_queue(NETISR_IP, m)` ⇒ ip_input runs with a NULL/torn-down rcvif ⇒
  NULL function-pointer call ⇒ panic.
- Downstream: the decapsulated multicast packet is forwarded by `X_ip_mforward` (:1154) /
  `ip_mdq`, which access `viftable`/`numvifs` **without** the token at entry, so a
  concurrent teardown also corrupts the forwarding path.

## Fix attempt + validation
`fix.diff` adds `lwkt_gettoken(&mroute_token)` to `X_ipip_input` (entry + all 4 return
paths). `lwkt_gettoken` does serialize cross-CPU on contention
(sys/kern/lwkt_token.c:686-716: `_lwkt_trytokref_spin` then `lwkt_switch()`).

Built the patched `ip_mroute.ko`, **objdump-verified** `lwkt_gettoken` at offset 0x14e +
4 `lwkt_reltoken` in `X_ipip_input`, installed (sha256 de5fc1… vs original 7a4a68…),
reloaded, re-ran the SAME PoC. **Result: still panics, identical signature.**

**Why the minimal fix is insufficient (fix_failed):** protecting only `X_ipip_input`'s
`v_ifp` read does not close the race, because the decapsulated multicast packet is
subsequently forwarded by `X_ip_mforward`/`ip_mdq` (:1154+), which read `viftable`/
`numvifs` **without** the token at entry; a concurrent `del_vif`/`X_ip_mrouter_done`
`bzero()`s `viftable` under the token, so the forwarding path still derefs zeroed vif
state ⇒ same NULL-pointer panic.

**Concrete next iteration for a complete fix:** the teardown paths (`del_vif` and
`X_ip_mrouter_done`) must synchronize against in-flight netisr packets before `bzero()` —
e.g. a `netisr` drain/barrier (analogous to `netisr_wait`) on teardown — **and/or** the
entry of `X_ip_mforward`/`ip_mdq` must acquire `mroute_token` for the full viftable walk.
This is a broader locking change beyond a single-function patch.

## PoC changes
- Wrote `poc.c` from scratch (no prior scaffold existed). Fixed `vifi_t` (was u_int8_t; the
  kernel's is `u_short`, sys/net/ip_mroute/ip_mroute.h:82 — first build returned EINVAL),
  and used the correct `SOCK_RAW`/`IPPROTO_IGMP` mrouter socket required by
  `ip_mrouter_init` (:571).

## Impact
Kernel panic / DoS. Reachable only with **root-configured multicast routing** (MRT_INIT is
privileged) plus concurrent reconfiguration; an unprivileged user cannot trigger it. Not a
privilege escalation — no memory-corruption primitive is attacker-shaped here, it is a
torn-down-state deref. Medium severity is appropriate (admin-config DoS; pim_input half is
dead code on GENERIC).