diff options
| author | Matthieu Baerts (NGI0) <matttbe@kernel.org> | 2025-01-29 13:24:32 +0100 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-02-08 09:58:16 +0100 |
| commit | b2bf3a2fdc71cc53b8be1fc2e5a5cf21708667e1 (patch) | |
| tree | eeca8707d4a7dd277e90bf331bccbc0ba976fcd4 /scripts/stackusage | |
| parent | 84ac44d9fed3a56440971cbd7600a02b70b5b32a (diff) | |
| download | linux-b2bf3a2fdc71cc53b8be1fc2e5a5cf21708667e1.tar.gz linux-b2bf3a2fdc71cc53b8be1fc2e5a5cf21708667e1.tar.bz2 linux-b2bf3a2fdc71cc53b8be1fc2e5a5cf21708667e1.zip | |
mptcp: blackhole only if 1st SYN retrans w/o MPC is accepted
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@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions
