Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4848110pxj; Wed, 9 Jun 2021 03:26:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoajonZwHCR2+wNkvnsYCaUt6p/EbKPPDGUOegqwBlaGChn/JpfQBGT4wHP0CYdu+DEIUa X-Received: by 2002:aa7:c354:: with SMTP id j20mr30093913edr.294.1623234414043; Wed, 09 Jun 2021 03:26:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623234414; cv=none; d=google.com; s=arc-20160816; b=cJ6OwOLzORcTq2P3zUm2AmR2/g4x15EzDmDuIOkaMb4gdE8kAM5V5vbHU22yU7P6HF CtRlh18Vq1z3Vbr10hwnt3TphugEk3woq9NzbQna7KtHv9cmnOEUFssMRYL+tLceJPAS 1c/9w4s9mpknGa0gUdNJOXet/G168ZIuwqgGsubNvEE9KG9SvmwzIdIVop/kl1oA5bi2 wylHAFuxU2R/rZtXi1z7rty08dK/VkbOTE9AFwQDY51kr+6m8gmfjFZw1C9mlfzLbEhs qTXaV13uTo3unV62KCJZNiyp5FrT4uBJ4GUPGgkInv8eBX4mgAivfvvKBRSE1hvlthnb bRlQ== 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=7aGzrHHmb/NAE52iyrEZUwp+PnZKdXRQXQ/vGCeykXE=; b=vgVk0vPBLDvI3ak6sSbkZWhNhqN8nS0v4sRhOy89lbMeCLO7J5ZdU6GsHxOGS04dc9 hJd41I0rjQKv8JEG6+lUkgTKeJ6zJ1f+dFoeXeCE0JmoVGE7CluQI3t9N4DmpNXbc1Qr 3oBmkujRvj8u4QrhenpuEdoCxfRhhl8tZvmmN2nmqxvIoSgKQqt6kg132ZTY5blkIp4Y Yo/VMND8I2Wf99TqImZBFBtGKRIQBVs6n8yH+BzRptPTD2GMJjwv5Tv8xmpqjElgFT/y e46eIW21yI30m68uKygkGDllmAwGV8hyqh4ZhsU9v8iOyl8k2Q5Z+hjK+TPJUpcWBci0 LBxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dcgmOj8Z; 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 18si2111641eji.288.2021.06.09.03.26.13; Wed, 09 Jun 2021 03:26:54 -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=dcgmOj8Z; 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 S237096AbhFHS5E (ORCPT + 99 others); Tue, 8 Jun 2021 14:57:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:49558 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236288AbhFHSuV (ORCPT ); Tue, 8 Jun 2021 14:50:21 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 880B061468; Tue, 8 Jun 2021 18:39:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623177570; bh=AaMwDixglMavB87jzoisnzjLq4r1/dPWSqnVRebWmBc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dcgmOj8ZcGrHAHb/FFKNnLmEXQ6CRQQ2yMzGBpQMCkuMhpu96r7K8QcqbRBRayoak AW37Owsw5YXzvzU6Gs8Buu4m++C4UHXSJ31Ri+QNXgvkb8mM0gi+Q0VYyupXbLMem3 i1fe78P82XfRtVaUx029YLGsDA89/D++EYkNhxE0= 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.10 021/137] mptcp: always parse mptcp options for MPC reqsk Date: Tue, 8 Jun 2021 20:26:01 +0200 Message-Id: <20210608175943.135195458@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210608175942.377073879@linuxfoundation.org> References: <20210608175942.377073879@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 bdd6af38a9ae..96b6aca9d0ae 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -527,21 +527,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