DF-3266 -- verification pack

Finding: pf_get_sport downward loop underflows when the pool range includes port 0

Status: not_reproduced / impact denial_of_service / confidence likely

What was run

guest: cc -O -o fillsyn fillsyn.c (raw SYN injector with valid checksums)

How to reproduce

guest: pfctl -f conf (port 0:65535 nat on lo0), fillsyn 127.0.0.1 9 fill, then trigger

Expected

rule accepted; full saturation (and thus the unterminating loop) not reached on this rig

See VERDICT.md for the full narrative and verdict.json for the persisted machine verdict. Artifacts: fillsyn.c, run.log.

DF-3266 verification

Kernel: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

Bottom line

Half verified, half refuted-in-practice: pfctl ACCEPTS a NAT pool whose port range includes 0 (nat ... port 0:65535 loads verbatim), and the downward loop for (tmp = cut - 1; tmp >= low; --tmp) with u_int16_t tmp provably underflows to 0xffff at low==0 (condition always true) - pf.c:3033. But saturating all candidate ports was not achievable on this rig: an external-destination fill wedges the QEMU slirp backend (65K pending host connects) before saturation, and a loopback fill collapses to ~10.7K concurrent states (local RSTs tear the half-open states down; a listener variant did not change the ceiling) while 194 million state-table searches were billed at 3.4M/s during the fill. The trigger connect therefore always found a free port (or was EPERM-blocked by pf) and never entered the unterminating loop. Admin-config-dependent DoS; fix (clamp low to 1, as the ICMP path already does) compile-validated.

Kernel references

• sys/net/pf/pf.c:3033-3050
• sys/net/pf/pf.c:3010-3012

Exploit chain

(none: availability/correctness finding; no privilege chain)

Fix

clamp low to 1 after the range swap

See fix.diff in this directory (git-apply-able against the read-only sys/ tree; applied only inside the disposable verification guest).

Reproduction

build: guest: cc -O -o fillsyn fillsyn.c (raw SYN injector with valid checksums)

run: guest: pfctl -f conf (port 0:65535 nat on lo0), fillsyn 127.0.0.1 9 fill, then trigger

expected: rule accepted; full saturation (and thus the unterminating loop) not reached on this rig

Notes on the PoC (what changed vs the finding sketch)

v1 used deliberately broken TCP checksums, which pf drops with EPERM from the raw sender; v2 computes correct checksums; destination moved inside the guest after the slirp wedge

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.