DF-3360 — pf scrub max-mss: 2-byte stack OOB read/write past opts[40] in pf_normalize_tcpopt()

What

pf_normalize_tcpopt() (sys/net/pf/pf_norm.c:1907-1957) clamps the TCP MSS option for scrub rules with max-mss N. The option walk:

u_char opts[TCP_MAXOLEN];                 /* :1915 — exactly 40 bytes  */
cnt = thoff - sizeof(struct tcphdr);      /* == 40 for th_off == 15    */
...
optlen = optp[1];
if (optlen < 2 || optlen > cnt) break;    /* optlen == 2 is accepted   */
switch (opt) {
case TCPOPT_MAXSEG:
        mss = (u_int16_t *)(optp + 2);    /* == opts + 40 with the tile below */
        if ((ntohs(*mss)) > r->max_mss) { /* OOB READ of opts[40..41]  */
                th->th_sum = pf_cksum_fixup(th->th_sum, *mss,
                    htons(r->max_mss), 0);
                *mss = htons(r->max_mss); /* OOB WRITE of opts[40..41] */
                rewrite = 1;
        }

A TCP header with th_off = 15 whose option space tiles as [38 bytes of filler][0x02 0x02] — an MSS option with declared option length 2 (instead of TCPOLEN_MAXSEG == 4) as the final option — makes optp == opts+38, optlen == 2 (accepted by the optlen > cnt check since cnt == 2), and mss == opts+40: two bytes past the 40-byte stack array. The read is unconditional; when the adjacent stack word (read big-endian) exceeds the rule's max-mss, a 2-byte value htons(max_mss) is written past the array. An option length of 3 gives a 1-byte OOB.

Secondary effect even when the write does not fire: th->th_sum is "fixed up" with a delta computed from the OOB-read stale-stack bytes and the header is copied back — a 2-byte stale-kernel-stack oracle in the forwarded packet's checksum for transit traffic.

Preconditions

• pf enabled with a scrub rule carrying max-mss (common on WAN edges; not the default empty ruleset).
• Attacker sends one TCP packet whose header ends in the malformed MSS option. Unauthenticated, remote, one packet per execution of the bug.

Guest verification (see VERDICT.md)

• Disassembly of the shipped /boot/kernel/pf.ko proves the unguarded access is compiled in: movzwl 0x2(%r15) / mov %ax,0x2(%r15) with %r15 = opts+38 (pf_normalize_tcpopt+0xba).
• 300,000 malformed-MSS packets through scrub in on lo0 all max-mss {64,1} executed the path (rule evaluations climbed) with the guest staying up: in this gcc -O2 build opts+40..41 lands in an 8-byte frame alignment-padding slot (rbp-0x30, unreferenced), so the OOB is inert on this exact binary — the defect is real (UB) and compiler-layout-dependent for impact.

Reproduce

# root on the guest:
kldload pf
printf 'scrub in on lo0 all max-mss 64\n' > /root/poc/mss.conf
pfctl -f /root/poc/mss.conf && pfctl -e
/root/poc/mss_oob 100000        # sends SYN, th_off=15, [38xNOP][0x02 0x02]
pfctl -sr -v                    # evaluations counter climbs; guest stays up

Fix

if (optlen != TCPOLEN_MAXSEG) break; in the TCPOPT_MAXSEG case — see fix.diff.

DF-3360 VERDICT

Reproduced? No — the defect is certain, the shipped build neutralizes it.

What was proven, and how

1. Source-level reachability (certain). pf_normalize_tcpopt() (sys/net/pf/pf_norm.c:1907-1957) pulls cnt = th_off*4 - 20 bytes into u_char opts[TCP_MAXOLEN] (= exactly 40, sys/netinet/tcp.h:149). The walk accepts an option with optlen == optp[1] as long as 2 <= optlen <= cnt. A final option [0x02, 0x02] after 38 bytes of filler (th_off == 15) leaves cnt == 2, passes the check, and executes mss = (u_int16_t *)(optp + 2) = opts+40: - ntohs(*mss) reads 2 bytes past the array (pf_norm.c:1941); - when the stale stack word (big-endian) exceeds r->max_mss, *mss = htons(r->max_mss) writes 2 bytes past the array (pf_norm.c:1944).

2. Compiled into the shipped binary (certain). Disassembly of /boot/kernel/pf.ko (INVARIANTS gcc80 -O2, see pf_normalize_tcpopt.dis): the loop guard is only optlen < 2 || optlen > cnt; the access is movzwl 0x2(%r15) (pf_normalize_tcpopt+0xba) with %r15 walkable to opts+38, and the store mov %ax,0x2(%r15) (+0x102). No bound vs the 40-byte array exists.

3. Runtime path execution (observed). scrub in on lo0 all max-mss 64 + 100,000 crafted packets: rule evaluations climbed to 416,675 and the packets were not dropped early (the option pull succeeds; the scrub rule has no port/address constraints). 200,000 more packets with max-mss 1 (write condition almost always true). Guest stable throughout, no console messages, no panic.

4. Why nothing manifests on this build. Frame layout from the same disassembly: opts lives at rbp-0x58; opts+40..41 = rbp-0x30 — an 8-byte alignment-padding slot between the array and the first pushed register (saved rbx at rbp-0x28). No instruction in the function references -0x30(%rbp). The OOB read returns stale stack; the conditional OOB write corrupts only that dead padding.

Impact assessment

• On the shipped gcc80 -O2 build: no runtime impact (padding), except a subtle secondary effect: th->th_sum is recomputed with a delta derived from the OOB-read stale bytes and the header is copied back into the packet — for transit traffic this leaks 2 bytes of stale kernel stack per packet into an observable checksum change.
• On any rebuild where a live local/spill lands at opts+40 (different compiler version, -O level, LTO, KASAN-style redzones, or simply a change in register pressure): a remotely-triggerable 2-byte kernel stack write adjacent to saved registers with a rule-chosen value — memory-corruption class.

Confidence in the defect: certain. Runtime manifestation on the audited binary: none. Status: not_reproduced / impact none (for this build), severity filed as Medium.

Fix

One line: if (optlen != TCPOLEN_MAXSEG) break; in the MAXSEG case (fix.diff). Not kernel-rebuilt for this finding (single-fix build budget was spent on DF-3362, whose fix is validated; the change is a pure additional guard on an option-parsing branch and cannot regress the well-formed path, which always has optlen == 4).

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.