From nobody Thu Sep 18 08:16:30 2025 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:ab0:35eb:0:0:0:0:0 with SMTP id w11csp2243121uau; Mon, 27 Jun 2022 18:03:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sh1ePgh20qjRLZ+EyNlig7dVJcI80zf8YpQ4gaFAJeXXS9H+22kvTs7DOv8wak7wZERZmt X-Received: by 2002:a05:6a02:117:b0:3fa:de2:357a with SMTP id bg23-20020a056a02011700b003fa0de2357amr14855675pgb.169.1656378181224; Mon, 27 Jun 2022 18:03:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656378181; cv=none; d=google.com; s=arc-20160816; b=nQ63FmPbsf1F0kd3dJJhOCS3PAIE1uYTg25IJbOfhaA7n43l8jLm4aqX972Owl6Wpd 7fGUsLh/jF8RiJ0lXmMjsHN5stm630f2nxjATfBWCENPAetTRTuFNZo2SK35UexGfU/6 v9jq/G/bubcIEctvMnR8pX+Lmng6NiF6WpHYLy3WFLmsFatKqfbHoXW/EWqe1wAeiAI4 6ARhkOAlITG5OTzg3ROPrtdmJxFjexd6BtKmYpun6Jb9ElIvqB47I55L7bG3rmxPoIwj ya61U7uurjIxarw1MXJ5/jvOqUD1gjHURfQj0mq1Isb6vFPQospDIik4YCWrcuPj2m0m SUiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=alomOcanNwrzOa0G3ZYpkhClqThI7Yc+knxOmUmnF4M=; b=w41JarRYtCO9qhCYvMQXf4PQvinm/iP9rha0XfQR+olZ1ibgNn8tpWL1eHxVue/vQM Kz5pWDEzYbowg3VkD/wxrnwOCmg6amvMUREUS4oOnb23023uNVVaWHB+okWv7sBIsCQI 5MtxmQYkovsNpnWEebslnZCj5tcYo2TD4+LaGong5FRME4DHljjqU7mxhr7uJ41DKejs SOzQ6/OfDHreypyTmo2sjtR7JUNyq/b8LySRhrCYJU5gzslOa+WFpQua7RovocnVerhW hepOIZIgHy9TAtuDFguqyh8sXy5uBkKiWruIc959lpHfBRUR1Kajr4GmP4sc5Bw75JZy dH0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=O4OvMPf9; spf=pass (google.com: domain of mptcp+bounces-5854-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.88.99 as permitted sender) smtp.mailfrom="mptcp+bounces-5854-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id a9-20020a17090a70c900b001ed45e83544si11188364pjm.31.2022.06.27.18.03.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2022 18:03:01 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-5854-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=O4OvMPf9; spf=pass (google.com: domain of mptcp+bounces-5854-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.88.99 as permitted sender) smtp.mailfrom="mptcp+bounces-5854-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 583F0280CC5 for ; Tue, 28 Jun 2022 01:03:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EDAA937B; Tue, 28 Jun 2022 01:02:54 +0000 (UTC) X-Original-To: mptcp@lists.linux.dev Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF07A370 for ; Tue, 28 Jun 2022 01:02:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656378173; x=1687914173; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cwCjWO7p4fYLgITbqWT1J/qDbZF+jfQ+eMSp5vmDTCk=; b=O4OvMPf9IjKb/cUDWSWAnVNr3ro/sC2L6L38vG8CEJ3scgH7vLIS/Guk OjF4rl76YGYgGPcD6FyGKDS1ffh55JEB7RFSW40Oor50y6pXjv4PH2+/g S/+CwLC5fWvVxEc0ZhcJfTZJ9tI+hi7Lk8ddXulaoKkoL9jxfROG/qNUz yD9+u8fWRsPnxZa1uIlWPsmIZUN1Pw77ZtrpqevO/4W59X17qZ0Yt2tzO shWt9jh2ZOJLzIHLtfutL64UWdvHlJwd/EkxMMO4otvvhMTqkbQjRyvzF sGjFdvjqyGaWayv+pI6ipqZGVoZPiPafw3pjnetaIoxy3xJdr4o3ZEii9 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10391"; a="270347719" X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="270347719" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2022 18:02:51 -0700 X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="692867396" Received: from cgarner-mobl1.amr.corp.intel.com (HELO mjmartin-desk2.intel.com) ([10.251.0.217]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2022 18:02:51 -0700 From: Mat Martineau To: netdev@vger.kernel.org Cc: Paolo Abeni , davem@davemloft.net, kuba@kernel.org, edumazet@google.com, fw@strlen.de, geliang.tang@suse.com, matthieu.baerts@tessares.net, mptcp@lists.linux.dev, Mat Martineau Subject: [PATCH net 6/9] mptcp: fix race on unaccepted mptcp sockets Date: Mon, 27 Jun 2022 18:02:40 -0700 Message-Id: <20220628010243.166605-7-mathew.j.martineau@linux.intel.com> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220628010243.166605-1-mathew.j.martineau@linux.intel.com> References: <20220628010243.166605-1-mathew.j.martineau@linux.intel.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Paolo Abeni When the listener socket owning the relevant request is closed, it frees the unaccepted subflows and that causes later deletion of the paired MPTCP sockets. The mptcp socket's worker can run in the time interval between such delete operations. When that happens, any access to msk->first will cause an UaF access, as the subflow cleanup did not cleared such field in the mptcp socket. Address the issue explicitly traversing the listener socket accept queue at close time and performing the needed cleanup on the pending msk. Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while still owning the subflow socket one. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available f= or each msk") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau --- net/mptcp/protocol.c | 5 +++++ net/mptcp/protocol.h | 2 ++ net/mptcp/subflow.c | 52 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 59 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index e63bc2bb7fff..e475212f2618 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2331,6 +2331,11 @@ static void __mptcp_close_ssk(struct sock *sk, struc= t sock *ssk, kfree_rcu(subflow, rcu); } else { /* otherwise tcp will dispose of the ssk and subflow ctx */ + if (ssk->sk_state =3D=3D TCP_LISTEN) { + tcp_set_state(ssk, TCP_CLOSE); + mptcp_subflow_queue_clean(ssk); + inet_csk_listen_stop(ssk); + } __tcp_close(ssk, 0); =20 /* close acquired an extra ref */ diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 9860179bfd5e..c14d70c036d0 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -306,6 +306,7 @@ struct mptcp_sock { =20 u32 setsockopt_seq; char ca_name[TCP_CA_NAME_MAX]; + struct mptcp_sock *dl_next; }; =20 #define mptcp_data_lock(sk) spin_lock_bh(&(sk)->sk_lock.slock) @@ -608,6 +609,7 @@ void mptcp_close_ssk(struct sock *sk, struct sock *ssk, struct mptcp_subflow_context *subflow); void mptcp_subflow_send_ack(struct sock *ssk); void mptcp_subflow_reset(struct sock *ssk); +void mptcp_subflow_queue_clean(struct sock *ssk); void mptcp_sock_graft(struct sock *sk, struct socket *parent); struct socket *__mptcp_nmpc_socket(const struct mptcp_sock *msk); =20 diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 03862103665d..63e8892ec807 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1723,6 +1723,58 @@ static void subflow_state_change(struct sock *sk) } } =20 +void mptcp_subflow_queue_clean(struct sock *listener_ssk) +{ + struct request_sock_queue *queue =3D &inet_csk(listener_ssk)->icsk_accept= _queue; + struct mptcp_sock *msk, *next, *head =3D NULL; + struct request_sock *req; + + /* build a list of all unaccepted mptcp sockets */ + spin_lock_bh(&queue->rskq_lock); + for (req =3D queue->rskq_accept_head; req; req =3D req->dl_next) { + struct mptcp_subflow_context *subflow; + struct sock *ssk =3D req->sk; + struct mptcp_sock *msk; + + if (!sk_is_mptcp(ssk)) + continue; + + subflow =3D mptcp_subflow_ctx(ssk); + if (!subflow || !subflow->conn) + continue; + + /* skip if already in list */ + msk =3D mptcp_sk(subflow->conn); + if (msk->dl_next || msk =3D=3D head) + continue; + + msk->dl_next =3D head; + head =3D msk; + } + spin_unlock_bh(&queue->rskq_lock); + if (!head) + return; + + /* can't acquire the msk socket lock under the subflow one, + * or will cause ABBA deadlock + */ + release_sock(listener_ssk); + + for (msk =3D head; msk; msk =3D next) { + struct sock *sk =3D (struct sock *)msk; + bool slow; + + slow =3D lock_sock_fast_nested(sk); + next =3D msk->dl_next; + msk->first =3D NULL; + msk->dl_next =3D NULL; + unlock_sock_fast(sk, slow); + } + + /* we are still under the listener msk socket lock */ + lock_sock_nested(listener_ssk, SINGLE_DEPTH_NESTING); +} + static int subflow_ulp_init(struct sock *sk) { struct inet_connection_sock *icsk =3D inet_csk(sk); --=20 2.37.0