Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp545434pxj; Tue, 18 May 2021 08:59:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqjOtYKf6oNQqJlCCu14VPV6MtEfVYWXdimhke9fqnaYWX5kjzmeJspHZhSZIwbXtac3p+ X-Received: by 2002:a17:906:1fcb:: with SMTP id e11mr805160ejt.46.1621353578468; Tue, 18 May 2021 08:59:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621353578; cv=none; d=google.com; s=arc-20160816; b=pHm2YoWEVHaJJwNStEy+Ot59WnvevSXw407HYfYH8F9CAfGM/1fwENIQpNCwh1N+KY 2oXGYsBcf/RgfHOlm8PJY3Fg3L6WDfTMo6+lOEwWaRNPUms1D9wW5h20+TF2f3AKckAF E6GBd7vx9Bi2jbvP808CI77Mzia4/tRghdv0E9bj3pCpzfHlkRCbnAExBzI/QkYpW9z7 k7YBqhqFT+J9trecCEhB2WMiTILTQheGuTkP46I7FGgf385k3BFJyfSWsgeyhjkWy5RZ 6N+VRghmoi9pAiWnVE1pBLODPPmP7xD2eV9Nyfcbxd9rcsC4d8IabTDhrZ7Y7CLYPbpC 5xoA== 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=L+i/vGT51UO99T/VP4eHmwRo2WVgEKYiy6jYqeJ3EFs=; b=d2M0G3VvxQT/mpYMVrYcsBSXo2nJmSmu5gn2uU/TdYS6Ddn1CCXbYanIhfLdWCqNZ3 3V72oBvT8pM6zPysVHcn1WTSqz9fP4EvUt7CFDQYUhUpCLoctL6Y3zGATkrjOz0t9bZP QpIG8NWyAJWGWoAgnQk3FSxZeOP42V3dHZiAVGNZceSjg12HBhRkIuf0zMAOLd/Ecu8z OsMRqfM7KbiO9sCQdRrNgC0x3BOdxqJawwp+GEm+YEQHlaOap8dA0EkXZs9ZDKtClZqq uoeDpYdzzYs1eM80tKlFkeA06pm3qWWNnKH0FJStW145eP9rb3LE7aiOzLldbAxM0FAV pyMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="wxSc/Fkw"; 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 h10si1923834edv.387.2021.05.18.08.59.15; Tue, 18 May 2021 08:59:38 -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="wxSc/Fkw"; 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 S1345946AbhEQP5j (ORCPT + 99 others); Mon, 17 May 2021 11:57:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:40234 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244158AbhEQPi4 (ORCPT ); Mon, 17 May 2021 11:38:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 269C661CF7; Mon, 17 May 2021 14:40:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621262459; bh=LCJvXIPQx6yoGnRPf/pz2z0summskwhGTtANjV5668k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wxSc/FkwTZRCJO40WLPTav3d0RpqL2m0/fAzew0UXTW3mgf6bVgoSxbTrvaitWaAU /o9p+XKKQP+lxJs8rkWAMtXVlS+GgAky+VvwMV6YStCzzM0vOK2Qr/xBCDD70jdw3R UQwf8qoybjHjNPsFFjdGlc1UaZR4XbfihASNcaiU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Florian Westphal , Paolo Abeni , Mat Martineau , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 192/289] mptcp: fix splat when closing unaccepted socket Date: Mon, 17 May 2021 16:01:57 +0200 Message-Id: <20210517140311.569815577@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140305.140529752@linuxfoundation.org> References: <20210517140305.140529752@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 578c18eff1627d6a911f08f4cf351eca41fdcc7d ] If userspace exits before calling accept() on a listener that had at least one new connection ready, we get: Attempt to release TCP socket in state 8 This happens because the mptcp socket gets cloned when the TCP connection is ready, but the socket is never exposed to userspace. The client additionally sends a DATA_FIN, which brings connection into CLOSE_WAIT state. This in turn prevents the orphan+state reset fixup in mptcp_sock_destruct() from doing its job. Fixes: 3721b9b64676b ("mptcp: Track received DATA_FIN sequence number and add related helpers") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/185 Tested-by: Florian Westphal Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20210507001638.225468-1-mathew.j.martineau@linux.intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/mptcp/subflow.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 6317b9bc8681..01a675fa2aa2 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -445,8 +445,7 @@ static void mptcp_sock_destruct(struct sock *sk) * ESTABLISHED state and will not have the SOCK_DEAD flag. * Both result in warnings from inet_sock_destruct. */ - - if (sk->sk_state == TCP_ESTABLISHED) { + if ((1 << sk->sk_state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) { sk->sk_state = TCP_CLOSE; WARN_ON_ONCE(sk->sk_socket); sock_orphan(sk); -- 2.30.2