Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp728705imm; Thu, 13 Sep 2018 06:56:17 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYDHrZpchk3nuEI9QHbBLDAP2yqS5+2AVC2zLxDUanYoP0q8tnvRV1psaQ2dRax33AefJ/Z X-Received: by 2002:a62:49d5:: with SMTP id r82-v6mr7553947pfi.245.1536846977692; Thu, 13 Sep 2018 06:56:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536846977; cv=none; d=google.com; s=arc-20160816; b=OaF6iFavYzEIvbSuW5wWyLgxvNOiUAu4RZi3MJL7LBseJgTPBI5NXlNpVxilC0IPKn 6itHMYNhnI5kOMNgPC6ConrkySXObWjPqckdtU0bDveGnz0LmwMS6weXrGbAv1v8B4ma MfvNOO2u2J6HRQMPz5XFABjZZqikDND+wNtJyOKuPlBehEIet7YPMCoRnYuyxi1ZRX4m RckIOUe4j/AUQp6/bP8UDODPKxjwgbyxQ/3Yci5X5a08xb9YiYGw89+gjKQKc9XU1tuH dhhKKRA6YdAQo7r/w7N/oOfu1Pe8pJLvOBhjACXlKsG0haqgPbODNxEE/8xSyMuchfs8 KveA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from; bh=Ey/P7ubwVSVQQLev/45k43BiDdJ1yseoRcKFGcSfPow=; b=0l/A23SjXMGBV8/Ay+8CFUhPhMHFlNZ1n0cbuAPpkmzIbCyljm0yLy32hMbXxcIqH7 DsHsVzKiB0fNrIwdZxU63e9fN0GPB4oJB8SbZlPUyDPedK9IngrZFkGInlXPBiBbbXQl Le3S9CRp5xCMpZJ3lAuLLL6SF3Mjw+sRZigtqE2opDg9DTo8j8WwFmBTz9MoQzco8Qot 9NXoCns7V8PatKBu5hHIkVaaVFpAdml7loW9bQWkKDAq+k5Ar6M95gOUOGT8kFbHFPHx 8a8+ZcOYnHLzNCEfRKiJC+VOcGQV0SVeRpUrvC437KfCDW/q2LGn/Wle5TDIVxPYYHhT 4xgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bb7-v6si4052349plb.359.2018.09.13.06.56.02; Thu, 13 Sep 2018 06:56:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731199AbeIMTET (ORCPT + 99 others); Thu, 13 Sep 2018 15:04:19 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33890 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728699AbeIMTET (ORCPT ); Thu, 13 Sep 2018 15:04:19 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id EB9A2D1C; Thu, 13 Sep 2018 13:54:42 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Borkmann , John Fastabend , Song Liu , Alexei Starovoitov , Sasha Levin Subject: [PATCH 4.18 064/197] tcp, ulp: fix leftover icsk_ulp_ops preventing sock from reattach Date: Thu, 13 Sep 2018 15:30:13 +0200 Message-Id: <20180913131844.084550052@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180913131841.568116777@linuxfoundation.org> References: <20180913131841.568116777@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Borkmann [ Upstream commit 90545cdc3f2b2ea700e24335610cd181e73756da ] I found that in BPF sockmap programs once we either delete a socket from the map or we updated a map slot and the old socket was purged from the map that these socket can never get reattached into a map even though their related psock has been dropped entirely at that point. Reason is that tcp_cleanup_ulp() leaves the old icsk->icsk_ulp_ops intact, so that on the next tcp_set_ulp_id() the kernel returns an -EEXIST thinking there is still some active ULP attached. BPF sockmap is the only one that has this issue as the other user, kTLS, only calls tcp_cleanup_ulp() from tcp_v4_destroy_sock() whereas sockmap semantics allow dropping the socket from the map with all related psock state being cleaned up. Fixes: 1aa12bdf1bfb ("bpf: sockmap, add sock close() hook to remove socks") Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp_ulp.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/ipv4/tcp_ulp.c +++ b/net/ipv4/tcp_ulp.c @@ -129,6 +129,8 @@ void tcp_cleanup_ulp(struct sock *sk) if (icsk->icsk_ulp_ops->release) icsk->icsk_ulp_ops->release(sk); module_put(icsk->icsk_ulp_ops->owner); + + icsk->icsk_ulp_ops = NULL; } /* Change upper layer protocol for socket */