| Message ID | d3e7a601036127035708ebe28359b8e0ad142b14.1594401165.git.pabeni@redhat.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | Matthieu Baerts |
| Headers | show |
| Series | mptcp: cope better with mp_join storm | expand |
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 90857d5da216..8eaf9eb8a29b 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -417,7 +417,7 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk, /* hopefully temporary handling for MP_JOIN+syncookie */ subflow_req = mptcp_subflow_rsk(req); - fallback_is_fatal = subflow_req->mp_join; + fallback_is_fatal = tcp_rsk(req)->is_mptcp && subflow_req->mp_join; fallback = !tcp_rsk(req)->is_mptcp; if (fallback) goto create_child;
When syncookie are in use, the TCP stack may feed into subflow_syn_recv_sock() plain TCP request sockets. We can't access mptcp_subflow_request_sock-specific fields on such sockets. Explicitly check the rsk ops to do safe accesses. Signed-off-by: Paolo Abeni <pabeni@redhat.com> --- Note: this fixes an slab-out-of-bounds on syncookied MP_JOIN req, but handling of such req is still problematic: we relay on the client closing the socket before the 3rd ack, otherwise the client socket will be created as plain TCP one - and again client will have to close it. --- net/mptcp/subflow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)