netdev - Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 May 2007 20:20:50 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm

On Tue, May 01, 2007 at 11:13:54AM -0400, Benjamin LaHaise (bcrl@...ck.org) wrote:
> Hello,

Hi Benjamin.

> While testing a failover scenario, I managed to trigger an ack storm 
> between a Linux box and another system.  Although the cause of this particular 
> ACK storm was due to the other box forgetting that it sent out a FIN (the 
> second node was unaware of the FIN the first sent in its dying gasp, which 
> is what I'm trying to fix, but it's a tricky race), the resulting Linux 
> behaviour wasn't very robust.  Is there any particularly good reason that 
> FIN flag gets cleared on a connection which is being shut down?  The trace 
> that motivates this can be seen at 
> http://www.kvack.org/~bcrl/ack-storm.log .  As near as I can tell, a 
> similar effect can occur between two Linux boxes if the right packets get 
> reordered/dropped during connection teardown.

Could you archive 24Mb file or cut more precise bits out of it?

> +++ b/net/ipv4/tcp_output.c
> -	TCP_SKB_CB(skb)->flags = flags & ~(TCPCB_FLAG_FIN|TCPCB_FLAG_PSH);
> +	TCP_SKB_CB(skb)->flags = flags & ~(TCPCB_FLAG_PSH);

Will it break 793 RFC:

while the FIN is considered
to occur after the last actual data octet in a segment in which it occurs.

...

In this case, a FIN segment can be constructed and placed on the
outgoing segment queue.  No further SENDs from the user will be
accepted by the TCP, and it enters the FIN-WAIT-1 state.
RECEIVEs are allowed in this state.  All segments preceding and
including FIN will be retransmitted until acknowledged.  When the
other TCP has both acknowledged the FIN and sent a FIN of its
own, the first TCP can ACK this FIN.  Note that a TCP receiving
a FIN will ACK but not send its own FIN until its user has
CLOSED the connection also.

According to your patch, several packets with fin bit might be sent,
including one with data. If another host does not receive fin
retransmit, then that logic is broken, and it can not be fixed by
duplicating fins, I would even say, that remote box should drop second
packet with fin, while it can carry data, which will break higher
connection logic.

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html