* [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence()
@ 2026-06-09 22:09 ` Simon Baatz
0 siblings, 0 replies; 5+ messages in thread
From: Simon Baatz via B4 Relay @ 2026-06-09 22:09 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, linux-kernel, Simon Baatz
From: Simon Baatz <gmbnomis@gmail.com>
Commit 1e3bb184e941 ("tcp: re-enable acceptance of FIN packets when
RWIN is 0") added a special case in tcp_sequence() to mirror the FIN
exception in tcp_data_queue(), which accepts bare in-order FINs even
when the advertised window is zero. That behavior is not
RFC-compliant, but was introduced in commit 2bd99aef1b19 ("tcp: accept
bare FIN packets under memory pressure") to break tight FIN/ACK loops
caused by broken clients.
However, the condition added by commit 1e3bb184e941 ("tcp: re-enable
acceptance of FIN packets when RWIN is 0") is broader than required
and allows other non-compliant packets as well.
Tighten the tcp_sequence() FIN exception to only allow packets where
the packet is a bare in-order FIN and only the FIN flag extends beyond
tcp_max_receive_window(). In particular, this exception is only
reachable if tcp_max_receive_window() is zero. Otherwise the packet is
already accepted by the normal sequence check.
The existing packetdrill test tcp_rcv_zero_wnd_fin.pkt exercises this
behavior already and does not need to be changed.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
---
net/ipv4/tcp_input.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ab7a4e5435a8..1eddae246963 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4812,18 +4812,21 @@ static enum skb_drop_reason tcp_sequence(const struct sock *sk,
const struct tcphdr *th)
{
const struct tcp_sock *tp = tcp_sk(sk);
+ u32 seq_limit;
if (before(end_seq, tp->rcv_wup))
return SKB_DROP_REASON_TCP_OLD_SEQUENCE;
- if (unlikely(after(end_seq, tp->rcv_nxt + tcp_max_receive_window(tp)))) {
- /* Some stacks are known to handle FIN incorrectly; allow the
- * FIN to extend beyond the window and check it in detail later.
+ seq_limit = tp->rcv_nxt + tcp_max_receive_window(tp);
+ if (unlikely(after(end_seq, seq_limit))) {
+ /* Some stacks are known to send bare FIN packets
+ * in a loop even if we send RWIN 0 in our ACK. Allow
+ * them here, they are handled later in tcp_data_queue().
*/
- if (!after(end_seq - th->fin, tp->rcv_nxt + tcp_receive_window(tp)))
+ if (seq == tp->rcv_nxt && end_seq - th->fin == tp->rcv_nxt)
return SKB_NOT_DROPPED_YET;
- if (after(seq, tp->rcv_nxt + tcp_max_receive_window(tp)))
+ if (after(seq, seq_limit))
return SKB_DROP_REASON_TCP_INVALID_SEQUENCE;
/* Only accept this packet if receive queue is empty. */
---
base-commit: 3abbe30231441f1fbb3305e9854c56a34650af53
change-id: 20260609-tcp_fin_more_restrictive-5bc808e87c6a
Best regards,
--
Simon Baatz <gmbnomis@gmail.com>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence()
@ 2026-06-09 22:09 ` Simon Baatz
0 siblings, 0 replies; 5+ messages in thread
From: Simon Baatz @ 2026-06-09 22:09 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, linux-kernel, Simon Baatz
Commit 1e3bb184e941 ("tcp: re-enable acceptance of FIN packets when
RWIN is 0") added a special case in tcp_sequence() to mirror the FIN
exception in tcp_data_queue(), which accepts bare in-order FINs even
when the advertised window is zero. That behavior is not
RFC-compliant, but was introduced in commit 2bd99aef1b19 ("tcp: accept
bare FIN packets under memory pressure") to break tight FIN/ACK loops
caused by broken clients.
However, the condition added by commit 1e3bb184e941 ("tcp: re-enable
acceptance of FIN packets when RWIN is 0") is broader than required
and allows other non-compliant packets as well.
Tighten the tcp_sequence() FIN exception to only allow packets where
the packet is a bare in-order FIN and only the FIN flag extends beyond
tcp_max_receive_window(). In particular, this exception is only
reachable if tcp_max_receive_window() is zero. Otherwise the packet is
already accepted by the normal sequence check.
The existing packetdrill test tcp_rcv_zero_wnd_fin.pkt exercises this
behavior already and does not need to be changed.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
---
net/ipv4/tcp_input.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ab7a4e5435a8..1eddae246963 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4812,18 +4812,21 @@ static enum skb_drop_reason tcp_sequence(const struct sock *sk,
const struct tcphdr *th)
{
const struct tcp_sock *tp = tcp_sk(sk);
+ u32 seq_limit;
if (before(end_seq, tp->rcv_wup))
return SKB_DROP_REASON_TCP_OLD_SEQUENCE;
- if (unlikely(after(end_seq, tp->rcv_nxt + tcp_max_receive_window(tp)))) {
- /* Some stacks are known to handle FIN incorrectly; allow the
- * FIN to extend beyond the window and check it in detail later.
+ seq_limit = tp->rcv_nxt + tcp_max_receive_window(tp);
+ if (unlikely(after(end_seq, seq_limit))) {
+ /* Some stacks are known to send bare FIN packets
+ * in a loop even if we send RWIN 0 in our ACK. Allow
+ * them here, they are handled later in tcp_data_queue().
*/
- if (!after(end_seq - th->fin, tp->rcv_nxt + tcp_receive_window(tp)))
+ if (seq == tp->rcv_nxt && end_seq - th->fin == tp->rcv_nxt)
return SKB_NOT_DROPPED_YET;
- if (after(seq, tp->rcv_nxt + tcp_max_receive_window(tp)))
+ if (after(seq, seq_limit))
return SKB_DROP_REASON_TCP_INVALID_SEQUENCE;
/* Only accept this packet if receive queue is empty. */
---
base-commit: 3abbe30231441f1fbb3305e9854c56a34650af53
change-id: 20260609-tcp_fin_more_restrictive-5bc808e87c6a
Best regards,
--
Simon Baatz <gmbnomis@gmail.com>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence()
2026-06-09 22:09 ` Simon Baatz
(?)
@ 2026-06-12 22:43 ` Jakub Kicinski
2026-06-12 23:40 ` Simon Baatz
-1 siblings, 1 reply; 5+ messages in thread
From: Jakub Kicinski @ 2026-06-12 22:43 UTC (permalink / raw)
To: Simon Baatz via B4 Relay, Eric Dumazet
Cc: gmbnomis, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
Paolo Abeni, Simon Horman, netdev, linux-kernel
On Wed, 10 Jun 2026 00:09:24 +0200 Simon Baatz via B4 Relay wrote:
> From: Simon Baatz <gmbnomis@gmail.com>
>
> Commit 1e3bb184e941 ("tcp: re-enable acceptance of FIN packets when
> RWIN is 0") added a special case in tcp_sequence() to mirror the FIN
> exception in tcp_data_queue(), which accepts bare in-order FINs even
> when the advertised window is zero. That behavior is not
> RFC-compliant, but was introduced in commit 2bd99aef1b19 ("tcp: accept
> bare FIN packets under memory pressure") to break tight FIN/ACK loops
> caused by broken clients.
>
> However, the condition added by commit 1e3bb184e941 ("tcp: re-enable
> acceptance of FIN packets when RWIN is 0") is broader than required
> and allows other non-compliant packets as well.
>
> Tighten the tcp_sequence() FIN exception to only allow packets where
> the packet is a bare in-order FIN and only the FIN flag extends beyond
> tcp_max_receive_window(). In particular, this exception is only
> reachable if tcp_max_receive_window() is zero. Otherwise the packet is
> already accepted by the normal sequence check.
>
> The existing packetdrill test tcp_rcv_zero_wnd_fin.pkt exercises this
> behavior already and does not need to be changed.
>
> Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
This is odd. You are sending this patch which shares a lot of
similarities with Eric's patch:
https://lore.kernel.org/all/20260608151452.706822-1-edumazet@google.com/
Why are you submitting your own patch instead of discussing it further
with Eric and letting him send v2?
Eric, how would you like to proceed?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence()
2026-06-12 22:43 ` Jakub Kicinski
@ 2026-06-12 23:40 ` Simon Baatz
2026-06-13 3:47 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: Simon Baatz @ 2026-06-12 23:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Simon Baatz via B4 Relay, Eric Dumazet, Neal Cardwell,
Kuniyuki Iwashima, David S. Miller, Paolo Abeni, Simon Horman,
netdev, linux-kernel
Hi Jakub,
On Fri, Jun 12, 2026 at 03:43:55PM -0700, Jakub Kicinski wrote:
> On Wed, 10 Jun 2026 00:09:24 +0200 Simon Baatz via B4 Relay wrote:
> > From: Simon Baatz <gmbnomis@gmail.com>
> >
> > Commit 1e3bb184e941 ("tcp: re-enable acceptance of FIN packets when
> > RWIN is 0") added a special case in tcp_sequence() to mirror the FIN
> > exception in tcp_data_queue(), which accepts bare in-order FINs even
> > when the advertised window is zero. That behavior is not
> > RFC-compliant, but was introduced in commit 2bd99aef1b19 ("tcp: accept
> > bare FIN packets under memory pressure") to break tight FIN/ACK loops
> > caused by broken clients.
> >
> > However, the condition added by commit 1e3bb184e941 ("tcp: re-enable
> > acceptance of FIN packets when RWIN is 0") is broader than required
> > and allows other non-compliant packets as well.
> >
> > Tighten the tcp_sequence() FIN exception to only allow packets where
> > the packet is a bare in-order FIN and only the FIN flag extends beyond
> > tcp_max_receive_window(). In particular, this exception is only
> > reachable if tcp_max_receive_window() is zero. Otherwise the packet is
> > already accepted by the normal sequence check.
> >
> > The existing packetdrill test tcp_rcv_zero_wnd_fin.pkt exercises this
> > behavior already and does not need to be changed.
> >
> > Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
>
> This is odd. You are sending this patch which shares a lot of
> similarities with Eric's patch:
> https://lore.kernel.org/all/20260608151452.706822-1-edumazet@google.com/
>
> Why are you submitting your own patch instead of discussing it further
> with Eric and letting him send v2?
That's what I understood from Eric's reply to my comments. He asked
for an alternative, so I sent this as a concrete sugggestion.
Sorry if that was not the right way to proceed. I'm happy to
continue the discussion in Eric's thread instead and treat this as
part of that discussion.
>
> Eric, how would you like to proceed?
--
Simon Baatz <gmbnomis@gmail.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence()
2026-06-12 23:40 ` Simon Baatz
@ 2026-06-13 3:47 ` Eric Dumazet
0 siblings, 0 replies; 5+ messages in thread
From: Eric Dumazet @ 2026-06-13 3:47 UTC (permalink / raw)
To: Simon Baatz
Cc: Jakub Kicinski, Simon Baatz via B4 Relay, Neal Cardwell,
Kuniyuki Iwashima, David S. Miller, Paolo Abeni, Simon Horman,
netdev, linux-kernel
On Fri, Jun 12, 2026 at 4:40 PM Simon Baatz <gmbnomis@gmail.com> wrote:
>
> Hi Jakub,
>
> On Fri, Jun 12, 2026 at 03:43:55PM -0700, Jakub Kicinski wrote:
> > On Wed, 10 Jun 2026 00:09:24 +0200 Simon Baatz via B4 Relay wrote:
> > > From: Simon Baatz <gmbnomis@gmail.com>
> > >
> > > Commit 1e3bb184e941 ("tcp: re-enable acceptance of FIN packets when
> > > RWIN is 0") added a special case in tcp_sequence() to mirror the FIN
> > > exception in tcp_data_queue(), which accepts bare in-order FINs even
> > > when the advertised window is zero. That behavior is not
> > > RFC-compliant, but was introduced in commit 2bd99aef1b19 ("tcp: accept
> > > bare FIN packets under memory pressure") to break tight FIN/ACK loops
> > > caused by broken clients.
> > >
> > > However, the condition added by commit 1e3bb184e941 ("tcp: re-enable
> > > acceptance of FIN packets when RWIN is 0") is broader than required
> > > and allows other non-compliant packets as well.
> > >
> > > Tighten the tcp_sequence() FIN exception to only allow packets where
> > > the packet is a bare in-order FIN and only the FIN flag extends beyond
> > > tcp_max_receive_window(). In particular, this exception is only
> > > reachable if tcp_max_receive_window() is zero. Otherwise the packet is
> > > already accepted by the normal sequence check.
> > >
> > > The existing packetdrill test tcp_rcv_zero_wnd_fin.pkt exercises this
> > > behavior already and does not need to be changed.
> > >
> > > Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
> >
> > This is odd. You are sending this patch which shares a lot of
> > similarities with Eric's patch:
> > https://lore.kernel.org/all/20260608151452.706822-1-edumazet@google.com/
> >
> > Why are you submitting your own patch instead of discussing it further
> > with Eric and letting him send v2?
>
> That's what I understood from Eric's reply to my comments. He asked
> for an alternative, so I sent this as a concrete sugggestion.
Yes this is fine, please next time includ a link to the 'other patch'
since this discussion
was started by someone :)
About your patch, I thought that it would be fine to allow a remote
peer to add a FIN
to a payload packet of N bytes even if RWIN == N
It seems the bug of your other stack is that the FIN can be sent with
no payload,
and this is a less broader case.
FIN storage (a bit) is there, we can generalize the acceptance of FIN for free ?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-06-13 3:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-09 22:09 [PATCH net-next] tcp: tighten the FIN exception in tcp_sequence() Simon Baatz via B4 Relay
2026-06-09 22:09 ` Simon Baatz
2026-06-12 22:43 ` Jakub Kicinski
2026-06-12 23:40 ` Simon Baatz
2026-06-13 3:47 ` Eric Dumazet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.