From nobody Wed Apr 24 00:01:17 2024 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 2E2E910E5 for ; Sat, 7 Jan 2023 01:20:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673054410; x=1704590410; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=rLa9uhqo22smwWT8uoZsIYmpnT97eCFJu2FvAdA2zjI=; b=fSubjnD73KQbOk9uyxx3fKo5Rfxr7oIULELRTZaMlgVnmSvm5i0OLZES IDbN7bfniSZqQF1u1h0+sFayil/PmYsB6oG1wFVMZ9Pr50kTSqkfW+FV1 W5UERRDRpsGdHkZ5ogCDMDqGCEtaXJVpuJtCwEx6A3SMOoTKN4l35bMMU OA7L6PLyaMmzynyuhqng0vZrzTXDy+xD3G/44uFrDp2u5Y4iU09IWAqfn RZMXYwSrVTDhlZXXMd7wC6vyQ1qlezGfEF9y348ip35TPKQwVXu9VaJkE et/D7yVKrAzNr1ds5pkX8fv67AMJnotfT+sC+7gJtmyXuav0MkdYzGNHj Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10582"; a="322672298" X-IronPort-AV: E=Sophos;i="5.96,307,1665471600"; d="scan'208";a="322672298" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2023 17:20:08 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10582"; a="649475319" X-IronPort-AV: E=Sophos;i="5.96,307,1665471600"; d="scan'208";a="649475319" Received: from mechevar-mobl.amr.corp.intel.com (HELO mjmartin-desk2.intel.com) ([10.209.66.63]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2023 17:20:07 -0800 From: Mat Martineau To: stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: Matthieu Baerts , pabeni@redhat.com, mptcp@lists.linux.dev, Mat Martineau , Jakub Kicinski Subject: [PATCH 5.15 1/2] mptcp: dedicated request sock for subflow in v6 Date: Fri, 6 Jan 2023 17:19:57 -0800 Message-Id: <20230107011959.448249-2-mathew.j.martineau@linux.intel.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230107011959.448249-1-mathew.j.martineau@linux.intel.com> References: <20230107011959.448249-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: Matthieu Baerts commit 34b21d1ddc8ace77a8fa35c1b1e06377209e0dae upstream. tcp_request_sock_ops structure is specific to IPv4. It should then not be used with MPTCP subflows on top of IPv6. For example, it contains the 'family' field, initialised to AF_INET. This 'family' field is used by TCP FastOpen code to generate the cookie but also by TCP Metrics, SELinux and SYN Cookies. Using the wrong family will not lead to crashes but displaying/using/checking wrong things. Note that 'send_reset' callback from request_sock_ops structure is used in some error paths. It is then also important to use the correct one for IPv4 or IPv6. The slab name can also be different in IPv4 and IPv6, it will be used when printing some log messages. The slab pointer will anyway be the same because the object size is the same for both v4 and v6. A BUILD_BUG_ON() has also been added to make sure this size is the same. Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connect= ions") Reviewed-by: Mat Martineau Cc: stable@vger.kernel.org # 5.15 Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski --- net/mptcp/subflow.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 7a5d816ad47e..c1d76ec65c42 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -483,7 +483,7 @@ static void subflow_finish_connect(struct sock *sk, con= st struct sk_buff *skb) mptcp_subflow_reset(sk); } =20 -static struct request_sock_ops mptcp_subflow_request_sock_ops __ro_after_i= nit; +static struct request_sock_ops mptcp_subflow_v4_request_sock_ops __ro_afte= r_init; static struct tcp_request_sock_ops subflow_request_sock_ipv4_ops __ro_afte= r_init; =20 static int subflow_v4_conn_request(struct sock *sk, struct sk_buff *skb) @@ -496,7 +496,7 @@ static int subflow_v4_conn_request(struct sock *sk, str= uct sk_buff *skb) if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST)) goto drop; =20 - return tcp_conn_request(&mptcp_subflow_request_sock_ops, + return tcp_conn_request(&mptcp_subflow_v4_request_sock_ops, &subflow_request_sock_ipv4_ops, sk, skb); drop: @@ -505,6 +505,7 @@ static int subflow_v4_conn_request(struct sock *sk, str= uct sk_buff *skb) } =20 #if IS_ENABLED(CONFIG_MPTCP_IPV6) +static struct request_sock_ops mptcp_subflow_v6_request_sock_ops __ro_afte= r_init; static struct tcp_request_sock_ops subflow_request_sock_ipv6_ops __ro_afte= r_init; static struct inet_connection_sock_af_ops subflow_v6_specific __ro_after_i= nit; static struct inet_connection_sock_af_ops subflow_v6m_specific __ro_after_= init; @@ -527,7 +528,7 @@ static int subflow_v6_conn_request(struct sock *sk, str= uct sk_buff *skb) return 0; } =20 - return tcp_conn_request(&mptcp_subflow_request_sock_ops, + return tcp_conn_request(&mptcp_subflow_v6_request_sock_ops, &subflow_request_sock_ipv6_ops, sk, skb); =20 drop: @@ -540,7 +541,12 @@ struct request_sock *mptcp_subflow_reqsk_alloc(const s= truct request_sock_ops *op struct sock *sk_listener, bool attach_listener) { - ops =3D &mptcp_subflow_request_sock_ops; + if (ops->family =3D=3D AF_INET) + ops =3D &mptcp_subflow_v4_request_sock_ops; +#if IS_ENABLED(CONFIG_MPTCP_IPV6) + else if (ops->family =3D=3D AF_INET6) + ops =3D &mptcp_subflow_v6_request_sock_ops; +#endif =20 return inet_reqsk_alloc(ops, sk_listener, attach_listener); } @@ -1791,7 +1797,6 @@ static struct tcp_ulp_ops subflow_ulp_ops __read_most= ly =3D { static int subflow_ops_init(struct request_sock_ops *subflow_ops) { subflow_ops->obj_size =3D sizeof(struct mptcp_subflow_request_sock); - subflow_ops->slab_name =3D "request_sock_subflow"; =20 subflow_ops->slab =3D kmem_cache_create(subflow_ops->slab_name, subflow_ops->obj_size, 0, @@ -1808,9 +1813,10 @@ static int subflow_ops_init(struct request_sock_ops = *subflow_ops) =20 void __init mptcp_subflow_init(void) { - mptcp_subflow_request_sock_ops =3D tcp_request_sock_ops; - if (subflow_ops_init(&mptcp_subflow_request_sock_ops) !=3D 0) - panic("MPTCP: failed to init subflow request sock ops\n"); + mptcp_subflow_v4_request_sock_ops =3D tcp_request_sock_ops; + mptcp_subflow_v4_request_sock_ops.slab_name =3D "request_sock_subflow_v4"; + if (subflow_ops_init(&mptcp_subflow_v4_request_sock_ops) !=3D 0) + panic("MPTCP: failed to init subflow v4 request sock ops\n"); =20 subflow_request_sock_ipv4_ops =3D tcp_request_sock_ipv4_ops; subflow_request_sock_ipv4_ops.route_req =3D subflow_v4_route_req; @@ -1824,6 +1830,18 @@ void __init mptcp_subflow_init(void) tcp_prot_override.release_cb =3D tcp_release_cb_override; =20 #if IS_ENABLED(CONFIG_MPTCP_IPV6) + /* In struct mptcp_subflow_request_sock, we assume the TCP request sock + * structures for v4 and v6 have the same size. It should not changed in + * the future but better to make sure to be warned if it is no longer + * the case. + */ + BUILD_BUG_ON(sizeof(struct tcp_request_sock) !=3D sizeof(struct tcp6_requ= est_sock)); + + mptcp_subflow_v6_request_sock_ops =3D tcp6_request_sock_ops; + mptcp_subflow_v6_request_sock_ops.slab_name =3D "request_sock_subflow_v6"; + if (subflow_ops_init(&mptcp_subflow_v6_request_sock_ops) !=3D 0) + panic("MPTCP: failed to init subflow v6 request sock ops\n"); + subflow_request_sock_ipv6_ops =3D tcp_request_sock_ipv6_ops; subflow_request_sock_ipv6_ops.route_req =3D subflow_v6_route_req; =20 --=20 2.39.0