Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2226473imm; Thu, 7 Jun 2018 07:21:30 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLnshkFCfCzXeqZ9gwpmbsT9tgyc3GgSB+E30nhz5C3UDJl+8TimUPGCCaa5rolWKnLjdOl X-Received: by 2002:a17:902:622:: with SMTP id 31-v6mr2247997plg.135.1528381290534; Thu, 07 Jun 2018 07:21:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528381290; cv=none; d=google.com; s=arc-20160816; b=aUZZnl7qtRUHa+zYI38YvUWRlJzAqMlV+W7OXiyea7uhLqaT8bGOlqz39vaYXDABa/ r2BEZd4qRsgUn5BAKG2C7RVhaMJAhfYhlZH5LloI77mYnTbx3JO6nXZyFyLOhrRb8drC QFUGcmjkZKtUSQXshCQUmstc9ifGPug/OJbheWu05gdjJtgpJ+zlxZnnDFzlc62kviFE p8TcaIoUNIENYXSB5WOyvV9tqlj99LPWGO3NbwiU17y6ZVXbHZ3QIDn+yyUeEddE4aUd RPkXTIc3fjNn4FBOiq7Lgio4elke085nOUprWcPIpuh/PrrbE9+jkve2uZAIbu4sIOC0 bFSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=KFRJpJSJ9yCZWBSAgppwXAJGoUVJzkn57PoleZNTH7g=; b=g9bVAzL+9jLlFmzFNALkMO+ZVVGDKI7OhB/+A+h7EGiP+LCadtsnDwyqrvVR3ttM34 HEPNzEru4NP2QugOq6iXtuv00t66uGKD0dTdyJN5E0GfPq0Oz8lXP4hZwAwFgSXsOTsf OJ1FQvtzmIKuF8MvUosoUNGYgZM+gLjzdDPY1erNcSpwKkhStHW82Flf5AJqeXuuQqfj 6eCObxwi/EW1MAsf26lygWhu3Lx/u77+ChF7T9JG42XgHXYM5sMmawNFafa9F/PoFuI3 Rt6pvnymFjtFk6BfGgk7/GsrtSTb7tcr4oAzaKmS+1Dt/KLcteQf1qdItasLGBCf8XUz mZTg== 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 t76-v6si10143634pgc.393.2018.06.07.07.21.16; Thu, 07 Jun 2018 07:21:30 -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 S933503AbeFGOT2 (ORCPT + 99 others); Thu, 7 Jun 2018 10:19:28 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:39498 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933086AbeFGOJN (ORCPT ); Thu, 7 Jun 2018 10:09:13 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbC-0005hL-Vo; Thu, 07 Jun 2018 15:09:11 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb9-00038s-WF; Thu, 07 Jun 2018 15:09:08 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "James Chapman" , "David S. Miller" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 290/410] l2tp: don't use inet_shutdown on tunnel destroy In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: James Chapman commit 76a6abdb2513ad4ea0ded55d2c66160491f2e848 upstream. Previously, if a tunnel was closed, we called inet_shutdown to mark the socket as unconnected such that userspace would get errors and then close the socket. This could race with userspace closing the socket. Instead, leave userspace to close the socket in its own time (our tunnel will be detached anyway). BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 IP: __lock_acquire+0x263/0x1630 PGD 0 P4D 0 Oops: 0000 [#1] SMP KASAN Modules linked in: CPU: 2 PID: 42 Comm: kworker/u8:2 Not tainted 4.15.0-rc7+ #129 Workqueue: l2tp l2tp_tunnel_del_work RIP: 0010:__lock_acquire+0x263/0x1630 RSP: 0018:ffff88001a37fc70 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 0000000000000088 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88001a37fd18 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000076fd R12: 00000000000000a0 R13: ffff88001a3722c0 R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88001ad00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000a0 CR3: 000000001730b000 CR4: 00000000000006e0 Call Trace: ? __lock_acquire+0xc77/0x1630 ? console_trylock+0x11/0xa0 lock_acquire+0x117/0x230 ? lock_sock_nested+0x3a/0xa0 _raw_spin_lock_bh+0x3a/0x50 ? lock_sock_nested+0x3a/0xa0 lock_sock_nested+0x3a/0xa0 inet_shutdown+0x33/0xf0 l2tp_tunnel_del_work+0x60/0xef process_one_work+0x1ea/0x5f0 ? process_one_work+0x162/0x5f0 worker_thread+0x48/0x3e0 ? trace_hardirqs_on+0xd/0x10 kthread+0x108/0x140 ? process_one_work+0x5f0/0x5f0 ? kthread_stop+0x2a0/0x2a0 ret_from_fork+0x24/0x30 Code: 00 41 81 ff ff 1f 00 00 0f 87 7a 13 00 00 45 85 f6 49 8b 85 68 08 00 00 0f 84 ae 03 00 00 c7 44 24 18 00 00 00 00 e9 f0 00 00 00 <49> 81 3c 24 80 93 3f 83 b8 00 00 00 00 44 0f 44 c0 83 fe 01 0f RIP: __lock_acquire+0x263/0x1630 RSP: ffff88001a37fc70 CR2: 00000000000000a0 Fixes: 309795f4bec2d ("l2tp: Add netlink control API for L2TP") Signed-off-by: James Chapman Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- net/l2tp/l2tp_core.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1415,17 +1415,10 @@ static void l2tp_tunnel_del_work(struct sock = sk->sk_socket; - /* If the tunnel socket was created by userspace, then go through the - * inet layer to shut the socket down, and let userspace close it. - * Otherwise, if we created the socket directly within the kernel, use + /* If the tunnel socket was created within the kernel, use * the sk API to release it here. - * In either case the tunnel resources are freed in the socket - * destructor when the tunnel socket goes away. */ - if (tunnel->fd >= 0) { - if (sock) - inet_shutdown(sock, 2); - } else { + if (tunnel->fd < 0) { if (sock) kernel_sock_shutdown(sock, SHUT_RDWR); sk_release_kernel(sk);