Commit e00431bc authored Jun 07, 2016 by Pau Espin Pedrol Committed by David S. Miller Jun 08, 2016

tcp: accept RST if SEQ matches right edge of right-most SACK block



RFC 5961 advises to only accept RST packets containing a seq number
matching the next expected seq number instead of the whole receive
window in order to avoid spoofing attacks.

However, this situation is not optimal in the case SACK is in use at the
time the RST is sent. I recently run into a scenario in which packet
losses were high while uploading data to a server, and userspace was
willing to frequently terminate connections by sending a RST. In
this case, the ACK sent on the receiver side (rcv_nxt) is frozen waiting
for a lost packet retransmission and SACK blocks are used to let the
client continue uploading data. At some point later on, the client sends
the RST (snd_nxt), which matches the next expected seq number of the
right-most SACK block on the receiver side which is going forward
receiving data.

In this scenario, as RFC 5961 defines, the RST SEQ doesn't match the
frozen main ACK at receiver side and thus gets dropped and a challenge
ACK is sent, which gets usually lost due to network conditions. The main
consequence is that the connection stays alive for a while even if it
made sense to accept the RST. This can get really bad if lots of
connections like this one are created in few seconds, allocating all the
resources of the server easily.

For security reasons, not all SACK blocks are checked (there could be a
big amount of SACK blocks => acceptable SEQ numbers). Furthermore, it
wouldn't make sense to check for RST in blocks other than the right-most
received one because the sender is not expected to be sending new data
after the RST. For simplicity, only up to the 4 most recently updated
SACK blocks (selective_acks[4] field) are compared to find the
right-most block, as usually those are the ones with bigger probability
to contain it.

This patch was tested in a 3.18 kernel and probed to improve the
situation in the scenario described above.

Signed-off-by: Pau Espin Pedrol <pau.espin@tessares.net>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Tested-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

parent 01e517f1

net/ipv4/tcp_input.c

+23 −3

Original line number	Diff line number	Diff line
		@@ -5159,6 +5159,7 @@ static bool tcp_validate_incoming(struct sock sk, struct sk_buff skb,
		const struct tcphdr *th, int syn_inerr)
		{
		struct tcp_sock *tp = tcp_sk(sk);
		bool rst_seq_match = false;

		/* RFC1323: H1. Apply PAWS check first. */
		if (tcp_fast_parse_options(skb, th, tp) && tp->rx_opt.saw_tstamp &&
		@@ -5195,13 +5196,32 @@ static bool tcp_validate_incoming(struct sock sk, struct sk_buff skb,

		/* Step 2: check RST bit */
		if (th->rst) {
		/* RFC 5961 3.2 :
		* If sequence number exactly matches RCV.NXT, then
		/* RFC 5961 3.2 (extend to match against SACK too if available):
		* If seq num matches RCV.NXT or the right-most SACK block,
		* then
		* RESET the connection
		* else
		* Send a challenge ACK
		*/
		if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt)
		if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
		rst_seq_match = true;
		} else if (tcp_is_sack(tp) && tp->rx_opt.num_sacks > 0) {
		struct tcp_sack_block *sp = &tp->selective_acks[0];
		int max_sack = sp[0].end_seq;
		int this_sack;

		for (this_sack = 1; this_sack < tp->rx_opt.num_sacks;
		++this_sack) {
		max_sack = after(sp[this_sack].end_seq,
		max_sack) ?
		sp[this_sack].end_seq : max_sack;
		}

		if (TCP_SKB_CB(skb)->seq == max_sack)
		rst_seq_match = true;
		}

		if (rst_seq_match)
		tcp_reset(sk);
		else
		tcp_send_challenge_ack(sk, skb);

Admin message