DF-3317 VERDICT — reproduced (remote-equivalent blind ICMPv6 PTB → t_maxseg=0 → tcp_close divide-by-zero panic)

Status: reproduced. Impact: panic (remote-unauthenticated-equivalent kernel DoS; protocol-state corruption, not a memory-write primitive). Confidence: certain.

What was proven, end to end, on the stock INVARIANTS guest

DragonFly dfbsd 6.5-DEVELOPMENT #0 (Thu Jul 2 06:02:54 UTC 2026, X86_64_GENERIC), stock kernel, no sysctl changes:

1. The v6 PTB path performs no sequence validation and no MTU floor. ptb6 -x forges ICMP6_PACKET_TOO_BIG, mtu=60, th_seq=0x41424344 (garbage — never validated) quoting the victim 4-tuple. Source: tcp_subr.c:1582-1590 (raw icmp6_mtu → arg), 1626-1630 (ports-only copy, in6_pcbnotify(..., tcp_mtudisc)). The v4 twin validates seq at 1509-1511; the v6 path does not — verified both in source and by experiment (the garbage seq was accepted).
2. t_maxseg driven to 0. after-PTB : t_state=5 t_maxseg=0 t_maxopd=0 (dumped via net.inet.tcp.pcblist — the world-readable sysctl). Mechanics: maxopd = 60 - (40+20) = 0 (1820-1823) stored at 1852/1871. With timestamps negotiated, mss = 0-12 = -12 and the unsigned clamp at 1868 (so->so_snd.ssb_hiwat < mss with mss int -12) yields garbage t_maxseg = 419430 — also observed (run4).
3. Kernel divide-by-zero panic on close. With t_rttupdated >= 16 (echo rounds; VJ timing works with TCP_NOOPT) and the ssthresh-save block entered (1006-1008; entered because rmx_ssthresh != 0 on the ::1 host route — seeded with route change -ssthresh 1024, which models the organic state left by any previously congested connection; dosavessthresh would also work), the aborting close (SO_LINGER{1,0} → tcp_drop → tcp_close) executes i = (i + tp->t_maxseg/2) / tp->t_maxseg (1013) with t_maxseg==0: - First reproduction: Fatal trap 18: integer divide fault while in kernel mode ... current process = Idle ... Stopped at tcp_close+0x66e: divq %r8,%eax — system-down panic, preceded by 12x tcpcb 0xfffff8008997b9a0: MSS (0) too small to hold options! (the kernel's own diagnostic on the corrupted tcpcb). - Second reproduction (identical signature, captured in panic.txt/panic_console_full.txt). - Two additional runs where the fault hit in the closing process's syscall context were delivered as pid NNN (ptb6), uid 0: exited on signal 11 (core dumped) — process kill instead of system panic.

Why root-local PoC == remote-unauthenticated attacker

The PoC uses a raw ICMPv6 socket (root-only) purely to inject the packet on lo0 from this host. The packet itself is bit-identical to what an off-path IPv6 spoofer sends: src = victim peer, dst = victim, checksum computed by the kernel exactly as a real router's stack would. No local knowledge beyond the 4-tuple is used — th_seq is garbage (proving the missing check), and 4-tuples are enumerable locally via the world-readable net.inet.tcp.pcblist (DF-0337) or guessable remotely. ICMPv6 is not filtered by default on inbound WAN/LAN on DragonFly, and IPv6 is enabled by default.

Primitive characterization (per contract)

• Write primitive: none — this is protocol-state corruption (t_maxseg, t_maxopd fully attacker-chosen within [0, 2^32-60] mapped through tcp_mtudisc arithmetic), so uid=0 escalation is not on the table.
• Ceiling demonstrated: persistent per-connection MSS corruption of any IPv6 TCP connection (blind), tiny-MSS packet amplification for mtu in (60,1279], garbage-huge t_maxseg for mtu in [41,59] ∪ timestamped-60, and kernel panic (fatal trap 18, remote-triggerable) for the mtu=60/no-options/close chain. Panic requires the victim connection to close with ≥16 RTT samples while the route has non-zero cached ssthresh — both are ordinary states for any real connection.

Fix validation

fix.diff adds the RFC 8200 §5.2 floor to tcp6_ctlinput's PRC_MSGSIZE handling (if (arg < IPV6_MMTU) goto out;), applied in-guest to /usr/src, make nativekernel + make installkernel, reboot:

• Baseline (stock kernel): after-PTB t_maxseg=0 + fatal trap 18 at tcp_close (see panic.txt, run.log).
• Patched kernel: after-PTB t_maxseg=16324/14336 (unchanged), no MSS(0) diagnostics, aborting close returns normally, guest healthy. → fix_status: fixed.

Recommended follow-up (not in fix.diff, needs a small restructure): copy the quoted th_seq and apply the v4-style [snd_una, snd_max) check (RFC 5927) to also defeat in-window-blind MSS shrinking for mtu ≥ 1280, i.e. legitimate-looking PTBs.

Known-findings cross-reference

• DF-0338 (v4 tcp_mtudisc forged-MTU → corrupted t_maxseg, Low): same sink function, but that finding is about the missing lower bound in tcp_mtudisc itself; DF-3317 is the missing input validation in the v6 dispatcher (no seq check + no 1280 floor) which additionally makes the attack blind (no ISN guess). The panic chain (tcp_subr.c:1013 division by t_maxseg==0) is new here.
• DF-0336/0337/0339: re-checked during this pass — all still present in tree (tcp6_getcred live so_cred at 1387; raw bcopy at 1285-1288; tcp_new_isn signed last_offset at 1674/1707/1742).

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.