DF-3419 — pfi_kif_update() walks the pf dynaddr TAILQ with no pf_token while pf_rm_rule() frees entries cross-CPU → kernel UAF / panic (pf_if.c:470-482 vs 673-689)

Root cause

Two unsynchronized users of struct pfi_kif.pfik_dynaddrs:

1. Walker (no pf_token) — pfi_ifaddr_event() (pf_if.c:905-916) runs in whatever thread changes an interface address (SIOCAIFADDR/-alias → EVENTHANDLER_INVOKE(ifaddr_event) from sys/netinet/in.c:634/691/726 and sys/netinet6/in6.c:803/852). It calls pfi_kif_update() under crit_enter() only — a CPU-local critical section that does not serialize against other CPUs:

c 470 TAILQ_FOREACH(p, &kif->pfik_dynaddrs, entry) 471 pfi_dynaddr_update(p);

pfi_dynaddr_update() then dereferences the entry's fields (pf_if.c:491-502) and panics on dyn->pfid_kif == NULL || dyn->pfid_kt == NULL.

2. Freer (under pf_token, different CPU) — every ruleset reload/remove (pfctl -f, pfctl -k, DIOCCHANGERULE) runs pf_rm_rule() (pf_ioctl.c:425-433) → pfi_dynaddr_remove():

c 681 TAILQ_REMOVE(&aw->p.dyn->pfid_kif->pfik_dynaddrs, aw->p.dyn, entry); 682 pfi_kif_unref(...); 683 aw->p.dyn->pfid_kif = NULL; 684 pfr_detach_table(aw->p.dyn->pfid_kt); 685 aw->p.dyn->pfid_kt = NULL; 686 kfree(aw->p.dyn, M_PFI);

An in-progress walk whose cached p points at an entry being removed sees the NULLed pfid_kt/pfid_kif (or, after the kfree, whatever reclaims the chunk) → panic: pfi_dynaddr_update: bad argument, or silent UAF-read/wild-pointer use if the chunk is reused.

This is the list-lifetime sibling of the known DF-0604 (global pfi_buffer data race): same missing-lock family, different object and primitive — DF-0604 corrupts table contents; this one walks freed objects.

Reproduce (guest, root; < 90 s to panic on the stock kernel)

kldload pf; kldload if_tap
ifconfig tap0 create; ifconfig tap0 10.99.0.1/24 alias
cat > /tmp/pf3419.conf  # 41 rules referencing (tap0:network); pfctl
                        # collapses them to 2 rules / 1-2 dynaddrs
pfctl -f /tmp/pf3419.conf
# loop A: address churn (fires ifaddr_event -> pfi_kif_update walk)
# loop B: ruleset reload (frees the previous dynaddrs under pf_token)
sh /tmp/stress.sh      # see run.sh in this pack

Observed (stock INVARIANTS kernel #0, Thu Jul 2 06:02:54 UTC 2026)

Baseline, 2/2 runs, panic in ~60-75 s:

panic: pfi_dynaddr_update: bad argument
cpuid = 0
pfi_kif_update.isra.5() at pfi_kif_update.isra.5+0x1e8
pfi_kif_update.isra.5() at pfi_kif_update.isra.5+0x1e8
pfi_ifaddr_event() at pfi_ifaddr_event+0x49
in_control_internal.part.7() at ...
Debugger("panic")

(panic.txt, panic.2.txt — the second from a fresh vm.sh reset boot.)

Primitive characterization (why this stops at panic, not uid=0)

The walk consumes attacker-influenced memory: once the freed pfi_dynaddr chunk is reclaimed with controlled content, TAILQ_FOREACH follows a controlled entry.tqe_next and pfi_dynaddr_update dereferences controlled pfid_kt/ pfid_kif pointers into pfi_table_update → pfr_set_addrs (controlled kernel-pointer deref/write chain). However both racing operations require root (pfctl ruleset changes on /dev/pf 0600, and address changes via ifconfig), so there is no unprivileged→root chain — the realistic impact ceiling of the race itself is a root-triggered kernel panic (remote-DoS-adjacent only insofar as in-kernel address events — DHCP/IPv6-RA processing — can supply the walk side while an admin reloads rules).

Fix validation

fix.diff adds lwkt_gettoken(&pf_token) around the four event-handler pfi_update++/pfi_kif_update() sections (pfi_attach_ifnet, pfi_detach_ifnet, pfi_group_change, pfi_ifaddr_event) so the walk serializes against pfioctl's rule removal.

• Kernel rebuilt in-guest (make nativekernel KERNCONF=X86_64_GENERIC, RC=0, installkernel OK) → #1: Sat Sep 12 10:51:52 UTC 2026.
• Re-run of the exact stress: 3× (8000 churn × 8000 reload) + 1× (16000 × 16000), all clean, guest healthy (~7 min total vs ~70 s to panic baseline) — patched_runs.log.
• Caveat: lwkt tokens are surrendered at blocking points inside the walk (pfi_table_update → netmsg waits), so the fix shrinks the race to those windows rather than eliminating it by construction; 4/4 clean stress runs empirically validate it at this workload. A follow-up that adds dynaddr refcounting (or walks under a non-surrendered spinlock) would close it completely.