Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4355772pxj; Tue, 8 Jun 2021 12:16:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyIO6yMD/7tzXzgom5CJ80+ces8A6ICApndLazuiIyZYfPpkRagSiKCn3ojSifhmQeO5Tpg X-Received: by 2002:a17:906:15c7:: with SMTP id l7mr25662748ejd.167.1623179785934; Tue, 08 Jun 2021 12:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623179785; cv=none; d=google.com; s=arc-20160816; b=pqBy8mZGAQemysvL8/NGspYfD1weynWvpphqcTYvPMTnt6EvkDfrWSNSKzYRfi+Kam aOMMV14aejVkNcPY7Gw5yp6DdAWYvPVJdXawrtXD9p0QeF6/OpDNLGVRXns5V3whazA8 RNTyr0qU0kZQ7iQaYNcJZPqdzC3kGP8H8WL5ocsl6bK0HHoTT34MviPnfG8j6pazHDEO hnj/AD4u/duKVPudsWcMgl5RyhAfASS3YRtn9fCJICbt8BuIKn5Wxi+TTW5B2q72y61s TrcMgA/wMsE4+rDGD96Tn8xXLnGN5FA00ZdR1DmZ7AJdUczvSUb7IymQx2INxWY5F3oQ 5jsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=KqhlQzke0Amiw/vj6hRBS6g7x9XZm/qAKPS6aSqngsU=; b=Yt6BQvqHJ5f+B4GHFCVCzkih+zksOdxox7nr+JfirvQ2zme/QhZuSmTFWkey2B/LeW wpWOTWHONesoXUQqOmB7vo8JbVX/BEzlv4DM/hsBT9gvdah7/7ib2NUg8tSgHmf/H4Sp CFQaob4i+sTbb69Z/0+h2XC5Mthahy2XAudwNTl0SFOzk1unLF58AJrklDrzDOuYX+X6 a3w9dORk9n37cLpfbZmzNmNT16QUTEBEfcwph2W7AiEoEhtU2SVXXOWJOn92WxoKppzt uJ/tAKHOL8zmn1bsqCcCR4Ta8HRG3gfg637gRF6WnFq+c9OUoR7qJ4qv2TWeTf65YOF5 r3ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qaQBvovU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l24si368342ejp.503.2021.06.08.12.16.02; Tue, 08 Jun 2021 12:16:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qaQBvovU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238465AbhFHTPE (ORCPT + 99 others); Tue, 8 Jun 2021 15:15:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:40012 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237121AbhFHTEO (ORCPT ); Tue, 8 Jun 2021 15:04:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id F04D461352; Tue, 8 Jun 2021 18:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623177959; bh=e7tfVzAIhSE1lqXwp9d2grNhkhxH/7cdTqBQYWGu11Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qaQBvovUwPgW5E4jTI5HxkqqVTDWZqvebVwRJakkEyOLy+WQk5dza7wYCCWFsyw1J pTS/oMj1LwnvvgyGL08tBuYFIxz8yCV/4qKv0oPtrxkrA1bAXM3agtwhm9qkRLFVNt tjC1vqFbtf3AorXBZMt/XFdXpGNECwFCR6e6BnNc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Matthieu Baerts , Paolo Abeni , Mat Martineau , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.12 025/161] mptcp: always parse mptcp options for MPC reqsk Date: Tue, 8 Jun 2021 20:25:55 +0200 Message-Id: <20210608175946.301772230@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210608175945.476074951@linuxfoundation.org> References: <20210608175945.476074951@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Paolo Abeni [ Upstream commit 06f9a435b3aa12f4de6da91f11fdce8ce7b46205 ] In subflow_syn_recv_sock() we currently skip options parsing for OoO packet, given that such packets may not carry the relevant MPC option. If the peer generates an MPC+data TSO packet and some of the early segments are lost or get reorder, we server will ignore the peer key, causing transient, unexpected fallback to TCP. The solution is always parsing the incoming MPTCP options, and do the fallback only for in-order packets. This actually cleans the existing code a bit. Fixes: d22f4988ffec ("mptcp: process MP_CAPABLE data option") Reported-by: Matthieu Baerts Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/mptcp/subflow.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 1936db3574d2..8878317b4386 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -608,21 +608,20 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk, /* if the sk is MP_CAPABLE, we try to fetch the client key */ if (subflow_req->mp_capable) { - if (TCP_SKB_CB(skb)->seq != subflow_req->ssn_offset + 1) { - /* here we can receive and accept an in-window, - * out-of-order pkt, which will not carry the MP_CAPABLE - * opt even on mptcp enabled paths - */ - goto create_msk; - } - + /* we can receive and accept an in-window, out-of-order pkt, + * which may not carry the MP_CAPABLE opt even on mptcp enabled + * paths: always try to extract the peer key, and fallback + * for packets missing it. + * Even OoO DSS packets coming legitly after dropped or + * reordered MPC will cause fallback, but we don't have other + * options. + */ mptcp_get_options(skb, &mp_opt); if (!mp_opt.mp_capable) { fallback = true; goto create_child; } -create_msk: new_msk = mptcp_sk_clone(listener->conn, &mp_opt, req); if (!new_msk) fallback = true; -- 2.30.2