DF-0430 — PoC evidence pack

Finding: Unauthenticated PFSYNC_ACT_CLR/DEL/DEL_C let attacker mass-destroy arbitrary pf state across every CPU. Severity (filed): High Verdict: NOT REPRODUCED — FALSE POSITIVE (dead code) Impact: none

TL;DR

DF-0430 cites case PFSYNC_ACT_CLR: (if_pfsync.c:542-608), DEL (:749) and DEL_C (:873) — all arms of the switch (action) inside pfsync_input() (a single function spanning if_pfsync.c:462-1006). pfsync_input is dead code: the only registration site (sys/netinet/in_proto.c:281-296) is wrapped in #ifdef NPFSYNC, and NPFSYNC is never defined anywhere in sys/, so the handler is never registered and no proto-240 packet can reach it. This is the identical root cause proven exhaustively for the sibling finding DF-0428.

Files

Reproduce

./build.sh
# (root on guest): kldload pf.ko; pfctl -e
./run.sh          # run as root (raw socket); expect NO state deletion, NO pfsyncstats

Expected on master DEV: the CLR packet is sent, but pfsync_input is never invoked (symbol absent from kernel.debug; no proto-240 handler registered), so no pf state is deleted. pfsyncstats stays empty.

Fix

No code change needed — false-positive. See VERDICT.md § Recommended fix.

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:

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.)