@@ -53,6 +53,12 @@ static void subflow_generate_hmac(u64 key1, u64 key2, u32 nonce1, u32 nonce2,
mptcp_crypto_hmac_sha(key1, key2, msg, 8, hmac);
}
+static bool mptcp_can_accept_new_subflow(const struct mptcp_sock *msk)
+{
+ return inet_sk_state_load((struct sock *)msk) == TCP_ESTABLISHED &&
+ READ_ONCE(msk->pm.accept_subflow);
+}
+
/* validate received token and create truncated hmac and nonce for SYN-ACK */
static struct mptcp_sock *subflow_token_join_request(struct request_sock *req,
const struct sk_buff *skb)
@@ -445,6 +451,7 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
} else if (subflow_req->mp_join) {
mptcp_get_options(skb, &mp_opt);
if (!mp_opt.mp_join ||
+ !mptcp_can_accept_new_subflow(subflow_req->msk) ||
!subflow_hmac_valid(req, &mp_opt)) {
SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
fallback = true;
So that we can easily perform some basic PM-related adimission checks before creating the child socket. Signed-off-by: Paolo Abeni <pabeni@redhat.com> --- Note: I initially used mptcp_can_accept_new_subflow() in subflow_token_join_request(), too. The goal was add a follow-up patch sending reset at rsk creation time in case of !can_accept but I dismissed such patch because it feel "insecure"/potentially dos prone send this early reset: an attacker could force an mptcp server to send reset packets towards arbitrary IP/ports. Additionally, after a quick look at mptcp.org, I could not find trace of such early reset - looks like resets for bad MP_JOINs are send only at syn_recv_sock() time. --- net/mptcp/subflow.c | 7 +++++++ 1 file changed, 7 insertions(+)