Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 23aeeec3 authored by Ilpo Jrvinen's avatar Ilpo Jrvinen Committed by David S. Miller
Browse files

[TCP] FRTO: Plug potential LOST-bit leak 



It might be possible that, in some extreme scenario that
I just cannot now construct in my mind, end_seq <=
frto_highmark check does not match causing the lost_out
and LOST bits become out-of-sync due to clearing and
recounting in the loop.

This may fix LOST-bit leak reported by Chazarain Guillaume
<guichaz@yahoo.fr>.

Signed-off-by: default avatarIlpo Jrvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 746aa32d

net/ipv4/tcp_input.c

+3 −1
Original line number Diff line number Diff line
@@ -1704,6 +1704,8 @@ static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag) 
	tcp_for_write_queue(skb, sk) {

		if (skb == tcp_send_head(sk))

			break;



		TCP_SKB_CB(skb)->sacked &= ~TCPCB_LOST;

		/*

		 * Count the retransmission made on RTO correctly (only when

		 * waiting for the first ACK and did not get it)...
@@ -1717,7 +1719,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag) 
		} else {

			if (TCP_SKB_CB(skb)->sacked & TCPCB_RETRANS)

				tp->undo_marker = 0;

			TCP_SKB_CB(skb)->sacked &= ~(TCPCB_LOST|TCPCB_SACKED_RETRANS);

			TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS;

		}



		/* Don't lost mark skbs that were fwd transmitted after RTO */