DF-3380 — pfsync callout handlers run in softclock thread without pf_token: deterministic INVARIANTS panic after SIOCSETPFSYNC

Impact

pfsyncioctl(SIOCSETPFSYNC) (if_pfsync.c:1167-1170) arms sc->sc_bulkfail_tmo with handler pfsync_bulkfail and a 5hz timeout. DragonFly callouts execute in the per-CPU softclock_handler thread (sys/kern/kern_timeout.c:491), which holds no lwkt tokens. pfsync_bulkfail() begins with ASSERT_LWKT_TOKEN_HELD(&pf_token) (if_pfsync.c:1621), so on any kernel built with options INVARIANTS the callout panics the kernel ~5 seconds after any successful pfsync syncdev configuration* — deterministically, no race required:

panic: assertion "LWKT_TOKEN_HELD_ANY(&pf_token)" failed in pfsync_bulkfail at /usr/src/sys/net/pf/if_pfsync.c:1621
cpuid = 2
pfsync_bulkfail() at pfsync_bulkfail+0x71
softclock_handler() at softclock_handler+0x1b8
Debugger("panic")

The same defect pattern exists in: - pfsync_timeout() (if_pfsync.c:1514-1522) → calls pfsync_sendout() which asserts the token at if_pfsync.c:1673; armed by pfsync_get_mbuf() (if_pfsync.c:1268); - pfsync_bulk_update() (if_pfsync.c:1552) — asserts the token at entry (currently unreachable: see DF-3379 — nothing schedules it, and the only sc_bulk_tmo arming passes pfsync_timeout instead).

On non-INVARIANTS (production) kernels the KKASSERT compiles out and the handlers run unserialized against pf_token holders instead — a locking-discipline violation that is currently benign only because the sync engine is dead (DF-3379: pfsyncif == NULL makes the handlers no-ops past the assert).

Secondary defect in the same lifecycle: pfsync_clone_destroy() (if_pfsync.c:203-206) stops the callouts with callout_stop(), which per sys/kern/kern_timeout.c "does not interlock against a callout that is in-progress" for non-lock-aided callouts, and then kfree(sc)s the softc (if_pfsync.c:222). A pfsync_bulkfail firing concurrently on another CPU would dereference/write the freed softc (sc->sc_bulk_tries++). callout_drain() is the correct destroy-time API.

Reachability / privilege

SIOCSETPFSYNC is privileged (caps_priv_check(SYSCAP_RESTRICTEDROOT), if_pfsync.c:1065-1066) — trigger requires root (as any pfsync configuration does). Hence: privileged local DoS. Severity Low; confidence certain (deterministic, reproduced on the stock INVARIANTS guest).

Note: DF's base ifconfig has no pfsync subcommands at all (no SIOCSETPFSYNC caller in sbin/ifconfig), so the trigger is a 60-line C program issuing the ioctl directly — byte-for-byte what a ported ifconfig would do.

Reproduce (exact, on stock INVARIANTS kernel)

cc -o /root/trigger_df3380 /root/trigger_df3380.c
kldload pf; ifconfig pfsync0 create      # pfsync0 may already exist
/root/trigger_df3380 lo0                 # syncdev=lo0 (multicast join on lo0 works)
# ~5 seconds later: panic (assertion above), guest drops into DDB

syncdev must be an interface whose multicast join succeeds; with tap0/vtnet0 on this guest in_addmulti failed and the ioctl returned ENOBUFS before arming the callout (if_pfsync.c:1143-1148) — lo0 works.

Fix validation (fix.diff in this pack)

• callout_drain() instead of callout_stop() in pfsync_clone_destroy()
• lwkt_gettoken(&pf_token) / lwkt_reltoken(&pf_token) around the bodies of pfsync_timeout, pfsync_bulk_update, pfsync_bulkfail (replacing the asserts)
• validated: kernel rebuilt in-guest (make nativekernel KERNCONF=X86_64_GENERIC), rebooted, same trigger re-run → no panic; callout fires harmlessly (12 retries then gives up), guest stays up; pfsync0 destroy with an armed callout also clean.

DF-3380 VERDICT

Status: reproduced — deterministic kernel panic, single privileged ioctl + 5 s wait. Impact: panic (privileged local DoS; any root-equivalent pfsync configuration step triggers it — on INVARIANTS/debug kernels, which is every kernel built from this tree's default GENERIC config: options INVARIANTS is in X86_64_GENERIC line for line).

How it reproduces (baseline, stock kernel #0)

1. kldload pf (loads the pf/pfsync code — if_pfsync.c is optional pf, conf/files:1574)
2. ifconfig pfsync0 create (clone exists; engine irrelevant)
3. SIOCSETPFSYNC with syncdev=lo0 (60-line C trigger — DF's ifconfig has no pfsync subcommands; the ioctl is exactly what a ported ifconfig would issue)
4. pfsyncioctl (if_pfsync.c:1064-1181) sets sc_sync_ifp, joins the multicast group on lo0, then arms sc->sc_bulkfail_tmo with 5*hz and handler pfsync_bulkfail (if_pfsync.c:1167-1170).
5. Five seconds later the per-CPU softclock_handler thread (kern_timeout.c:491) runs pfsync_bulkfail, whose first statement is ASSERT_LWKT_TOKEN_HELD(&pf_token) (if_pfsync.c:1621). The callout thread holds no tokens →

panic: assertion "LWKT_TOKEN_HELD_ANY(&pf_token)" failed in pfsync_bulkfail at /usr/src/sys/net/pf/if_pfsync.c:1621
cpuid = 2
pfsync_bulkfail() at pfsync_bulkfail+0x71
softclock_handler() at softclock_handler+0x1b8

Guest dead in DDB; ssh sessions die; vm.sh status => down. Observed 2026-09-11 21:14:25Z (panic.txt, boot_panic_full.log, run.baseline.log).

Precondition detail verified live: syncdev must be an interface whose 224.0.0.240 membership join succeeds — with tap0 (no carrier) and vtnet0 the ioctl returned ENOBUFS from pfsync_in_addmulti (if_pfsync.c:1143-1148) before arming the callout; lo0 works. That ENOBUFS path is itself notable: on vtnet0 (UP, RUNNING, MULTICAST, carrier on) in_addmulti(224.0.0.240, vtnet0) still failed — the pfsync multicast join is fragile, another symptom of the vestigial interface.

Why the assert is a real defect and not just debug noise

The handlers mutated by this bug family also run on production (non-INVARIANTS) kernels — there the KKASSERT compiles away and pfsync_bulkfail runs unserialized against pf_token holders (sc fields, pf state via request_update/sendout). It is benign today only because the engine is dead (DF-3379: pfsyncif == NULL forces the no-op paths); the same callout wiring defect would be a data race the moment the engine is revived. Related members of the family, same fix: - pfsync_timeout() (if_pfsync.c:1514-1522) → pfsync_sendout() asserts the token at if_pfsync.c:1673; armed from pfsync_get_mbuf() (if_pfsync.c:1268) — currently unreachable with the engine dead, but identically broken. - pfsync_bulk_update() asserts at entry (if_pfsync.c:1552). - pfsync_clone_destroy() (if_pfsync.c:203-206) uses callout_stop() on all three callouts and then kfree(sc) (if_pfsync.c:222); per kern_timeout.c, callout_stop "does not interlock against a callout that is in-progress", so an in-flight pfsync_bulkfail on another CPU would touch freed memory (sc->sc_bulk_tries++). callout_drain() is the destroy-time API.

Exploit chain

Not applicable beyond DoS: the primitive is a guaranteed wrong-context execution + assert; with INVARIANTS compiled out there is no memory-safety consequence while the engine stays dead (all touched paths no-op on pfsyncif == NULL). If the engine is ever revived without this fix, the same callouts become unserialized writers racing pf_token holders.

Fix validation (fix.diff — applied in-guest only, sys/ tree untouched here)

make nativekernel KERNCONF=X86_64_GENERIC + installkernel + reboot (kernel #1, 2026-09-11 21:24:50Z, build.log.final): - baseline #0: panic at if_pfsync.c:1621, guest dead (run.baseline.log) - patched #1: identical trigger → callout armed → SURVIVED_CALLOUT, guest up, and dmesg shows pfsync0 demoted group carp to 1 — proof pfsync_bulkfail executed to completion under the newly-acquired pf_token instead of asserting (run.fixed.log). ifconfig pfsync0 destroy returned EINVAL (softc still holds the lo0 membership / ifp busy) — unrelated to the fix; the drain path is exercised at module unload.

fix_status: fixed (baseline reproduced 1, patched reproduced 0).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.