# DF-0430 — Verdict: NOT REPRODUCED (FALSE POSITIVE — dead code)

## One-line verdict
DF-0430 claims unauthenticated `PFSYNC_ACT_CLR/DEL/DEL_C` packets let an
attacker mass-destroy arbitrary pf state across every CPU
(`sys/net/pf/if_pfsync.c:542-608`, `:749`, `:873`). **This code path is
unreachable**: every cited line lives inside `pfsync_input()`, which is
**dead code** on the default kernel. The same root cause already proven for
the sibling finding **DF-0428** applies verbatim here.

## What the finding cited (and where it lives)
- `sys/net/pf/if_pfsync.c:542-608` — `case PFSYNC_ACT_CLR:` — reads an
  attacker-controlled `creatorid` and, when `ifname[0]==0`, walks
  `tree_id[]` on **every CPU** calling `pf_unlink_state()` for matching
  states (`:561-574`); non-empty `ifname` walks `pf_statetbl[]` (`:584-601`).
- `sys/net/pf/if_pfsync.c:749` — `case PFSYNC_ACT_DEL:` — unlinks individual
  states by attacker `id/creatorid`.
- `sys/net/pf/if_pfsync.c:873` — `case PFSYNC_ACT_DEL_C:` — same, with a
  client-id match (`:881-893`).

**Critical structural fact:** `pfsync_input()` is ONE function spanning
`sys/net/pf/if_pfsync.c:462-1006` (the `done:` label is at `:1003`, closing
brace at `:1006`). The `switch (action)` begins at `:541`; `case
PFSYNC_ACT_CLR:` at `:542` is the 1st arm, `DEL` and `DEL_C` later arms of the
very same switch. So all three arms DF-0430 cites are the **same dead
function** as DF-0428 — not separate sinks.

## Why it is a false positive (dead code — inherited from DF-0428)
`pfsync_input` is registered as the `IPPROTO_PFSYNC` (240) input handler in
exactly one place, and that place is compiled out:

```c
sys/netinet/in_proto.c:281:#ifdef NPFSYNC
sys/netinet/in_proto.c:288:	.pr_input = pfsync_input,
sys/netinet/in_proto.c:296:#endif	/* NPFSYNC */
```

`NPFSYNC` is **never defined anywhere** in `sys/` — exhaustive grep returns
only the two gate lines (`in_proto.c:281` and `:296`). No `#define NPFSYNC`,
no `options NPFSYNC` in `sys/conf/options`, no option in any kernel config.
→ The `.pr_input = pfsync_input` protosw entry is **compiled out of the static
kernel**. With no protosw carrying `pr_protocol=240`, `ip_init`
(`sys/netinet/ip_input.c:343-351`) leaves `ip_protox[240]` pointing at the
IPPROTO_RAW wildcard, so any proto-240 packet is dispatched to `rip_input`
(`ip_input.c:409-415`) — **never to `pfsync_input`**. `pf.ko` does not
dynamically register a handler either (it exports `pfsync_input`/`pfsyncattach`
as symbols but references neither `inetsw` nor `protosw`).

The honest comment at `if_pfsync.c:486` — *"This function is not yet called
from anywhere"* — is accurate.

## Definitive evidence (re-confirmed on this run, #0 with-src unpatched)
1. **Static kernel symbol:** `nm /boot/kernel/kernel.debug | grep -w pfsync_input`
   → **ABSENT**. The function is not even linked into the running kernel.
2. **Module symbol, unreferenced:** `nm /boot/kernel/pf.ko | grep pfsync_input`
   → `0000000000003040 T pfsync_input`; `grep inetsw|protosw` → none. The
   module carries the code but never registers it.
3. **No pfsync protocol registered:** `netstat -sp pfsync` → empty (no
   pfsyncstats block at all) even with `pf.ko` loaded + `pfctl -e` +
   `pfsync0` present.
4. **Live injection, zero effect:** injecting the exact `PFSYNC_ACT_CLR`
   (`ifname=""`, `creatorid=0xdeadbeef`) packet DF-0430 describes
   (`./inject_clr 10.0.2.99 224.0.0.240 0xdeadbeef`) deleted **no** pf state,
   produced **no** `pfsyncs_ipackets` increment, and **no** observable pfsync
   activity. See `run.log`.

## Impact of this false positive
None. The "mass-delete arbitrary pf state across every CPU" primitive DF-0430
describes is not reachable. `pfsync_input` is dormant; the CLR/DEL/DEL_C arms
are unreachable code inside a dead function. (DragonFly's in-kernel pfsync
*receiver* was never finished/wired up — only the *sender* side
`pfsync_sendout` is functional.)

## Build / run (reproduce the negative result)
```
./build.sh        # cc -o inject_clr inject_clr.c   (unprivileged build OK)
# (root on guest): kldload pf.ko; pfctl -e
./run.sh          # injects the CLR mass-delete trigger; expects NO effect
```

## PoC changes
- `inject_clr.c` — NEW. Crafts a raw `ip_p=240`, `ip_ttl=255` packet carrying
  `pfsync_header{action=PFSYNC_ACT_CLR}` + `pfsync_state_clr{ifname="",
  creatorid=0xdeadbeef}` — the exact trigger cited at `if_pfsync.c:542-608`
  (the every-CPU `tree_id[]` walk). The same dead-code conclusion covers the
  DEL (`:749`) and DEL_C (`:873`) arms since they are siblings in the same
  switch.
- No `exploit.c` — there is no memory-corruption primitive; this is an
  auth/availability claim whose entire surface is dead code.

## Recommended fix
**No code change needed: false-positive.** The cited `PFSYNC_ACT_CLR/DEL/DEL_C`
arms (`if_pfsync.c:542-895`) are inside `pfsync_input()`, which is unreachable
on the default kernel and on `pf.ko`-loaded kernels because the
`#ifdef NPFSYNC` registration block in `in_proto.c:281-296` is compiled out
(`NPFSYNC` is never defined) and `pf.ko` does not register a handler.
If the project ever wires up the pfsync *receiver* (defines `NPFSYNC`,
finishes the integration), then the missing-source-authentication concern
becomes real; but that is gated on first making the code reachable, which is
not the case today. (Matches the conclusion of sibling DF-0428.)