mptcp: Avoid one more mptcp_sock_def_error_report

One more case, how we can end up in a situation where the meta-socket is
closed while in infinite mapping while the subflow is not yet:

+0      `sysctl -w net.ipv4.tcp_retries1=1`
+0      `sysctl -w net.ipv4.tcp_retries2=2`
+0      `sysctl -w net.ipv4.tcp_orphan_retries=1`
+0      `sysctl -w net.mptcp.mptcp_enabled=1`
+0      socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0      setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
+0      setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0      bind(3, {sa_family = AF_INET, sin_port = htons(13000), sin_addr = inet_addr("192.168.0.1")}, ...) = 0
+0      listen(3, 1) = 0

+0      socket(..., SOCK_STREAM, IPPROTO_TCP) = 5
+0      setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0      bind(5, {sa_family = AF_INET, sin_port = htons(13001), sin_addr = inet_addr("192.168.0.1")}, ...) = 0
+0      listen(5,1) = 0

+0      < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7,mp_capable key_a> sock(3)
+0      > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7,mp_capable key_b> sock(3)
+0.1    < . 1:1(0) ack 1 win 257 <mp_capable key_a key_b> sock(3)
+0      accept(3, ..., ...) = 4

+0      < P. 1:11(10) ack 1 win 257 <dss dack4 dsn4> sock(4)
+0      > . 1:1(0) ack 11 <dss dack4=11> sock(4)

+0      read(4, ..., 100) = 10

+0      write(4, ..., 100) = 100
+0      > P. 1:101(100) ack 11 <dss dack4=11 dsn4> sock(4)
+0      write(4, ..., 100) = 100
+0      > P. 101:201(100) ack 11 <dss dack4=11 dsn4> sock(4)

+0      < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7,mp_join_syn address_id=0 token=sha1_32(key_b)> sock(5)
+0      > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7, mp_join_syn_ack backup=0 address_id=0 sender_hmac=trunc_l64_hmac(key_b key_a) > sock(5)
+0      < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7,mp_join_syn address_id=0 token=sha1_32(key_b)> sock(5)
+0      > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7, mp_join_syn_ack backup=0 address_id=0 sender_hmac=trunc_l64_hmac(key_b key_a) > sock(5)
+0      < . 1:1(0) ack 1 win 32792 <mp_join_ack sender_hmac=full_160_hmac(key_a key_b)> sock(5)
+0      mp_join_accept(5) = 6

+0      > . 1:1(0) ack 1 <...> sock(6) // reliably mp_join_ack

+0      < F. 1:1(0) ack 1 win 257 <dss dack4=201 dsn4 FIN> sock(6)
+0      > . 1:1(0) ack 2 <dss dack4=12> sock(6)

+0.1    shutdown(4, SHUT_WR) = 0
+0      > F. 1:1(0) ack 2 <dss dack4 dsn4 FIN> sock(6)
+0      < . 2:2(0) ack 2 win 542 <dss dack4=202> sock(6)
// The DATA_FIN has now been acknowledged on the second subflow. Now,
// meta->snd_una == 202, while tp->mptcp->last_end_data_seq == 201

+0.1    < . 11:11(0) ack 101 win 257 sock(4)
// Now, we fall back. If we would make a call to mptcp_restart_sending,
// snd_nxt would be set to 201, while snd_una is 202. It is an
// inconsistent state and bad things will happen...

+0      > R. 201:201(0) ack 11 <dss dack4=12> sock(4)

+0      close(4) = 0

+2      `sysctl -w net.ipv4.tcp_retries1=3`
+0      `sysctl -w net.ipv4.tcp_retries2=15`
+0      `sysctl -w net.ipv4.tcp_orphan_retries=0`

Fix this, by just killing a subflow if its last_end_data_seq is less
than snd_una. Because, in that case we can't recover... There is
effectively a hole in the sequence-number space and all we can do is
kill the subflow.

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
(cherry picked from commit ccd600a)
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
(cherry picked from commit bec571e)
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>

net/mptcp/mptcp_input.c

@@ -1624,6 +1624,13 @@ bool mptcp_handle_ack_in_infinite(struct sock *sk, const struct sk_buff *skb,
 		return true;
 	}
 
+	/* We have sent more than what has ever been sent on the master subflow.
+	 * This means, we won't be able to seamlessly fallback because there
+	 * will now be a hole in the sequence space.
+	 */
+	if (before(tp->mptcp->last_end_data_seq, meta_tp->snd_una))
+		return true;
+
 	mpcb->infinite_mapping_snd = 1;
 	mpcb->infinite_mapping_rcv = 1;
 	mpcb->infinite_rcv_seq = mptcp_get_rcv_nxt_64(mptcp_meta_tp(tp));