From: Matthieu Baerts (NGI0) <matttbe@xxxxxxxxxx>
commit e598d8981fd34470b78a1ae777dbf131b15d5bf2 upstream.
The Fixes commit mentioned this:
> An MPTCP firewall blackhole can be detected if the following SYN
> retransmission after a fallback to "plain" TCP is accepted.
But in fact, this blackhole was detected if any following SYN
retransmissions after a fallback to TCP was accepted.
That's because 'mptcp_subflow_early_fallback()' will set 'request_mptcp'
to 0, and 'mpc_drop' will never be reset to 0 after.
This is an issue, because some not so unusual situations might cause the
kernel to detect a false-positive blackhole, e.g. a client trying to
connect to a server while the network is not ready yet, causing a few
SYN retransmissions, before reaching the end server.
Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole")
Cc: stable@xxxxxxxxxxxxxxx
Reviewed-by: Mat Martineau <martineau@xxxxxxxxxx>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@xxxxxxxxxx>
Signed-off-by: Paolo Abeni <pabeni@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
net/mptcp/ctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/mptcp/ctrl.c
+++ b/net/mptcp/ctrl.c
@@ -405,9 +405,9 @@ void mptcp_active_detect_blackhole(struc
MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPCAPABLEACTIVEDROP);
subflow->mpc_drop = 1;
mptcp_subflow_early_fallback(mptcp_sk(subflow->conn), subflow);
- } else {
- subflow->mpc_drop = 0;
}
+ } else if (ssk->sk_state == TCP_SYN_SENT) {
+ subflow->mpc_drop = 0;
}
}
Patches currently in stable-queue which might be from matttbe@xxxxxxxxxx are
queue-6.12/selftests-net-lib-openvswitch-extend-cflags-to-keep-.patch
queue-6.12/mptcp-handle-fastopen-disconnect-correctly.patch
queue-6.12/mptcp-consolidate-suboption-status.patch
queue-6.12/mptcp-blackhole-only-if-1st-syn-retrans-w-o-mpc-is-accepted.patch
queue-6.12/mptcp-pm-only-set-fullmesh-for-subflow-endp.patch
queue-6.12/selftests-mptcp-extend-cflags-to-keep-options-from-e.patch
