Re: git: fc63421de9f6 - main - pf: allows TCP RST packets in the backwards window if ACK matches

From: Harry Schmalzbauer <freebsd_at_omnilan.de>
Date: Sat, 31 Oct 2026 16:24:40 UTC
On 2025-09-17 16:15, Kristof Provost wrote:
> The branch main has been updated by kp:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=fc63421de9f69ed67aad7bae29712fca2f570693
>
> commit fc63421de9f69ed67aad7bae29712fca2f570693
> Author:     Kristof Provost <kp@FreeBSD.org>
> AuthorDate: 2025-08-25 13:49:22 +0000
> Commit:     Kristof Provost <kp@FreeBSD.org>
> CommitDate: 2025-09-17 14:15:15 +0000
>
>      pf: allows TCP RST packets in the backwards window if ACK matches
>      
>      TCP reset packets are generated for the sequence numbers that have
>      been acknowledged.  Our pf(4) is quite strict regarding sequence
>      numbers of reset packets to avoid evil connection drops.  It expected
>      exact match and did not allow a sequence window for resets.  As pf
>      tracks neither gaps in the sequence space nor the acknowledged data,
>      it does not know where exactly the reset is expected by the TCP
>      stack.
>      
>      Problem was that legit reset packets before a gap but not at the
>      highest sequence numbers were blocked by pf.  Solution is to fix
>      pf_tcp_track_full().  Now it allows sequence number windows if the
>      packet has ACK+RST flags set and the acknowlege number matches
>      perfectly.  This still prevents reset number guessing by an attacker.
>      
>      Curiously the TCP stack behaves correctly and accepts only resets
>      before the gap.  pf only allowed resets after the final data.  So
>      any reset was ignored by the system.  When the other side processed
>      the challenge ACK, the situation could be fixed.
>      
>      bug reported and fix tested by Lucas Aubard with Johan Mazel, Gilles
>      Guette and Pierre Chifflier; OK sashan@
>      
>      Obtained from:  OpenBSD, bluhm <bluhm@openbsd.org>, 12e4c257ea
>      Sponsored by:   Rubicon Communications, LLC ("Netgate")


Hello,

is guess this is a desirable MFC candidate for 15.2, is it?

Thanks,

-harry