# DF-0513 — IPv6 firewall chain mutation raced with concurrent ip6_fw_chk

## Verdict: NOT-REPRODUCED at runtime (race window too tight on default GENERIC);
## code-path CONFIRMED real and exercisable from an unprivileged user.

## Mechanism (confirmed at code level)

`ip6_fw_chain` is a global singly-linked list (sys/net/ip6fw/ip6_fw.c:115)
walked **lock-free** by `ip6_fw_chk()` (sys/net/ip6fw/ip6_fw.c:498) on every
IPv6 packet (called from sys/netinet6/ip6_input.c:318 and
sys/netinet6/ip6_output.c:612).  The mutators only take
`crit_enter()/crit_exit()`, which masks interrupts on the *current* CPU
but does NOT serialize against other CPUs running `ip6_fw_chk`:

- `del_entry6` (sys/net/ip6fw/ip6_fw.c:902-923): `LIST_REMOVE` +
  `crit_exit()` + `kfree(fcp->rule)` + `kfree(fcp)` — **kfree happens
  AFTER crit_exit**, so a concurrent walker on another CPU can be
  derefing the rule while it's being freed.
- `ip6_fw_ctl` FLUSH path (sys/net/ip6fw/ip6_fw.c:1126-1135): same
  kfree-after-crit_exit pattern.
- `zero_entry6` (sys/net/ip6fw/ip6_fw.c:944-950) and `IPV6_FW_GET`
  (sys/net/ip6fw/ip6_fw.c:1106): walk the chain with no crit at all.
- The SKIPTO inner loop (sys/net/ip6fw/ip6_fw.c:741-744) keeps walking
  `chain->chain.le_next->rule` across multiple nodes, widening any
  race window against a concurrent delete.

## Secondary observation: NO PRIVILEGE CHECK on the mutator path

`ip6_output.c` cases `IPV6_FW_ADD/DEL/FLUSH/ZERO/GET` (sys/netinet6/
ip6_output.c:1534-1551, 1760-1774) dispatch directly to
`ip6_fw_ctl_ptr` with **no `priv_check` / `caps_priv_check_self`**.
Once the `ip6fw` module is loaded (one-time root setup, realistic for
any IPv6 router), **any unprivileged user can add/del/flush firewall
rules** via `setsockopt(IPPROTO_IPV6, IPV6_FW_*)`.  The PoC exploits
this to drive the race entirely from the `maxx` (uid 1001) account.

## Reproduction attempt (runtime)

PoC `df0513.c` runs two threads as the unprivileged `maxx` user:

- Thread A: opens AF_INET6 SOCK_DGRAM, floods packets to ::1:9999 to
  drive `ip6_output` → `ip6_fw_chk`.
- Thread B: opens AF_INET6 SOCK_DGRAM, alternates
  `setsockopt(IPV6_FW_ADD)` and `setsockopt(IPV6_FW_DEL)` for rule
  numbers 500..599.

On the buggy kernel:

```
DF-0513: racing ip6_fw_chk against chain mutation for 20s
[sender] sent 0 pkts, errors 28325              <- 28k chk calls
[mutator] add=21446 del=21446 err=0 (iters 21446)  <- 21k add+21k del cycles
```

A second run with 4 concurrent adders + 4 senders + 1 flusher for 30 s
drove ~520 k add/del cycles and ~159 k flushes — still no panic.  Guest
stayed up; dmesg showed only the (informational) `len=X, want 200`
messages from earlier probes.

**Why no panic despite the race being exercised millions of times:**
The window between `LIST_REMOVE` and `kfree` is very narrow (a few
instructions), `LIST_REMOVE` only rewrites the *neighbor's* next/prev
pointers (leaving the victim's pointers intact), and the freed slab
memory stays mapped and readable (its old contents remain valid until
reused).  INVARIANTS slab checks (`chunk_mark_free` bitmap / WEIRD_ADDR
poison) only trip on the *next allocation* of the freed chunk, not on a
UAF read by a concurrent walker.  Winning the race reliably would need
either CPU pinning (the guest has no `cpuset` utility) or a tighter
SKIPTO inner-loop pattern — both beyond the scope of a 30 s flood.

**Conclusion: code-path confirmed, race real, runtime panic not
triggered in the test window.**  Medium severity is appropriate (the
race exists and is unprivileged-reachable, but is not a one-shot
reproducible panic).

## Fix

`fix.diff` introduces a `lwkt_token ip6_fw_token` and takes it across:
- the entire `ip6_fw_chk` walk (acquire at entry, release before each
  return),
- `add_entry6`, `del_entry6`, `zero_entry6`, `IPV6_FW_GET`, `IPV6_FW_FLUSH`
  mutators (acquire around the crit section).
- Additionally moves `kfree(rule)` and `kfree(fcp)` INSIDE the
  crit_enter/exit window in `del_entry6` and FLUSH so the free is
  atomic w.r.t. the local CPU and the token-held walker.

`lwkt_token` is the DragonFly idiom for this kind of global state —
it's a non-recursive token that serializes all takers across CPUs and
is automatically released/reacquired on msgport switch, so it's safe
to hold across the (non-sleeping) chain walk.

## Build / run

```
ssh dfbsd 'kldload ip6fw'    # one-time root setup
ssh dfbsd-maxx 'mkdir -p poc/DF-0513'
scp findings/poc/DF-0513/{df0513.c,build.sh,run.sh} dfbsd-maxx:poc/DF-0513/
ssh dfbsd-maxx 'cd poc/DF-0513 && sh ./build.sh && sh ./run.sh 20'
# watch dmesg / dfbsd-qemu/boot.log for panic signature
```