Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp442157pxj; Tue, 18 May 2021 06:54:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrsfMr23vnWmzEwvBMya64Jgdb6m9vjh8QK4W38RamLKgSJsin6rDHHbcLuwCq2c1RaN36 X-Received: by 2002:a05:6402:26d1:: with SMTP id x17mr7251532edd.14.1621346080071; Tue, 18 May 2021 06:54:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621346080; cv=none; d=google.com; s=arc-20160816; b=xXjxjh19lL3YVpvknQkrcKTn44Z+qOTtN09itXpQFMzaRWeOaQPw8l8q7X2CEsjn+E anvW78muhU4/3CdFOkNthGKAiMXGbu8WRCUEPPk87QZ0yF6quR5iUxhdPkD8zKB/qBPA ElWc0QnnAzUBcReRmFIud8irUO8cwcvLp6GOnDL0ZX2J/5cYsvXtj5yNU1SLbwWkTKsZ TZuYk3Y16Z4Rv/H3UHa1ZSSXY0fKyME8+Ilft9y/aAgRhy8PHmlBNobo4D57xZCW6qef 41pR70b9ceWsuOQSaEK6ghpC8FvyA/OB3l5wYQfpN8lVN9xrsMptZ4w9F5HzX8ipr4ay V9IA== 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=Bly7HwrkKUgTvLPJo8i+wJK/4ObVVVjS4pd6NvQrfwk=; b=Wi7SNwslTud4vV0i0gzyV7iO4g/PM6krK0LPphhT7tDlfhtI7N+3V7Z04bdmK0aJE9 66YhltA4vnwTEoTtT3KU6kriesh64oFoYgSgsGaRnZQiCytP/dG0DurnJg8ek0szG410 B36aU+4/251bETyOld2CDJBqXrB6gjnuDQSG01c8QLYmy772IiJMr0Jv3s4RZMcnC9Ky fSN7NYO8HGKdtO/FvEOJhDOLWfPAyumWliX3hCPr9iChJ8PgQ11WKBg2WKDQqCRGotfK JZcibLwDBJlvmpbD9K4KnTXZQOYSmt+y8096zGRta8x4uh0RaU1aUP/PuJ+p6bq+1xe/ +rKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eI11Hfuf; 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 h15si19239987ejq.124.2021.05.18.06.54.13; Tue, 18 May 2021 06:54:40 -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=eI11Hfuf; 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 S1343952AbhEQPkD (ORCPT + 99 others); Mon, 17 May 2021 11:40:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:41358 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245102AbhEQPYi (ORCPT ); Mon, 17 May 2021 11:24:38 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 83AD261C95; Mon, 17 May 2021 14:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621262156; bh=9Pck8uEsAuHLM+Qc0nQL61vL9H2IKMCi+aB92EwLo40=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eI11HfufFZz3rbPUAG+ZKlhfVZow0l+RcHFbc+Os4v/EBH+ARVCUgFz+yzQFwEIzj xMgNoIbKfJ2M9u3V0DNe4S4Ge9eT4du46ra1C4SHdYGUNaHrsIQdAdB97OScMQjUfX ijHBXpy4ux5atqIMGQEfJ4rXk4BQIyAeo9wdnBaw= 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.11 228/329] mptcp: fix splat when closing unaccepted socket Date: Mon, 17 May 2021 16:02:19 +0200 Message-Id: <20210517140309.831036661@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140302.043055203@linuxfoundation.org> References: <20210517140302.043055203@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 f97f29df4505..371a114f3a5f 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -479,8 +479,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