Message ID | 20230130154438.1373750-1-syoshida@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2251384wrn; Mon, 30 Jan 2023 07:48:14 -0800 (PST) X-Google-Smtp-Source: AK7set9VHIzl6ma34cU+pbegKF8ahbK8JGd4s4mtFPyEu50J08P+BVLEcVHdn8m8tL1hUoJ26Swj X-Received: by 2002:a17:907:7628:b0:878:8009:2177 with SMTP id jy8-20020a170907762800b0087880092177mr14902065ejc.53.1675093694004; Mon, 30 Jan 2023 07:48:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675093693; cv=none; d=google.com; s=arc-20160816; b=Ns8zJDe8jXNNi6ia/UYy13yNgfVG/KqoMOSF8h5sq9P7StsNdLOi1JUg6aRJxpxu6f zmcM4VLE7cqMlydIZO39yY1iYK0tnP5W2Yl4Vz0QSY4BKpoN2PvB/vVmJL34Lolsuc25 G92HjAscOXAY5xVl5OL6eHWmc/t4E3Cfur8qxBbSPdNxMPQtf/JtvXWV7sK1HwmKQuRl 023261TvCydxO7m7Nrp9lcKVj1xho6otcPMnjflvGT0x5EpEXbA2l6itFXRK6G+TkYCd HuubtySSnsNETesXzjMqenKzIrh54fYKONS9yDfuS9kXufaDxjIY/VXEQxifi57MlB64 VZ9Q== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=XRAqDvpdOweYOp5rKoRnwrLbtMo4U87gO0dmZD+DZl8=; b=FDCUVG3rQykL+GxC4sGC3FirpgfbuburGds3sFTHiBi9sek8mwG61kOxyUM9/IEmeg Y4vLsHwHLsY9SMsrbaQDzJvhFmOgFzSP78gXQURMJmHJ+d3k9yhX8JpQkAmzPBUb5FNR iZJnzt4jyRPwi/03dQk6dPyt05X7ZIu9pLqDsJzIMf0R5/PPee89Jqpib8aPpi4hFKkB nTUMzGrDrUS5c/Hmt0x2LFdi2OCMi2P4SRXYwflv6XnniqGkbpeEQWd4uDwNR1aa2Em3 LA2BdYl1NimwFe/FH0xXa97KXnlGEDVbNe+TjooW0C8vNNmdKEbW2d+ECgo3Mk5IF5tl BiRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ib9tmd6T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id vl11-20020a17090730cb00b0088ac4402980si1113545ejb.489.2023.01.30.07.47.50; Mon, 30 Jan 2023 07:48:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ib9tmd6T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237025AbjA3PqI (ORCPT <rfc822;n2h9z4@gmail.com> + 99 others); Mon, 30 Jan 2023 10:46:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237500AbjA3Ppp (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Jan 2023 10:45:45 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3ACB3EFD8 for <linux-kernel@vger.kernel.org>; Mon, 30 Jan 2023 07:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675093495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=XRAqDvpdOweYOp5rKoRnwrLbtMo4U87gO0dmZD+DZl8=; b=ib9tmd6T81o6xquV7W+ysOD93QZv+L4/I2AIvxF9A4ubGdOOTWldamW2tNpST8s+spMYem P/WaVQCAzUosHp2ZyzyWBgL92fg4P44MGApDTRWMUdA4t91ZkLBPlJ2EC5J+sFdApr1Ly+ T/027iLuDQUg8IYXB0vJUIiVG0hwMus= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-88-vseZfI8tP_6BkmjycL97iQ-1; Mon, 30 Jan 2023 10:44:53 -0500 X-MC-Unique: vseZfI8tP_6BkmjycL97iQ-1 Received: by mail-pf1-f198.google.com with SMTP id h11-20020a056a00230b00b00593b9e6ee79so1633683pfh.8 for <linux-kernel@vger.kernel.org>; Mon, 30 Jan 2023 07:44:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XRAqDvpdOweYOp5rKoRnwrLbtMo4U87gO0dmZD+DZl8=; b=XrSZYxQ0/loYxIOPP6nwbd1MfnoqBJzmVibfjxQvlUaU4H+NdC+/bcKxZIMimFZ5Bo xMwTHg5fcfYH0rc50/p1ZdLBYuHEvyXY63FGwUBo5zgSRXQCqIu1iDw8GdYiZq06odAh eW3gdwc5PVnn/qIHwqgw8sg6Q4j3X8xCN9vzyFpqRVh/B9RNzkCeKfk/FY7QFJcNIXgc wGGJw5UL2Gg11INj1bXrr9wF3FvhTEReE90IUUc9PznkWakJJfAjK/3XRWPyfvXQ/3zJ lgN6GXx9uRKIJGeoSeGyuo363TctKPRIBdHOVKm68i5AstmFngrNEXNAB2blRfIC1JgM RKHA== X-Gm-Message-State: AFqh2kpKUOMO43d5rTLFzIAoE/5Oye2tQUqH+5+VdUt8ERg6VkFvLoes vCA/EWyoTbGPy7HWcP6579wZJOAosLcpngv6DSmo8J5EfWu3evHzhoOii5x6hNsKyDyrFL+ppUz hr4oXtrdYF1GG8tQ7modMJkxl X-Received: by 2002:a17:90b:390b:b0:22b:b1cd:cce with SMTP id ob11-20020a17090b390b00b0022bb1cd0ccemr38598610pjb.33.1675093492643; Mon, 30 Jan 2023 07:44:52 -0800 (PST) X-Received: by 2002:a17:90b:390b:b0:22b:b1cd:cce with SMTP id ob11-20020a17090b390b00b0022bb1cd0ccemr38598587pjb.33.1675093492345; Mon, 30 Jan 2023 07:44:52 -0800 (PST) Received: from localhost.localdomain ([240d:1a:c0d:9f00:ca6:1aff:fead:cef4]) by smtp.gmail.com with ESMTPSA id mp1-20020a17090b190100b002298e0641b6sm9654421pjb.27.2023.01.30.07.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jan 2023 07:44:52 -0800 (PST) From: Shigeru Yoshida <syoshida@redhat.com> To: jchapman@katalix.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Shigeru Yoshida <syoshida@redhat.com> Subject: [PATCH] l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register() Date: Tue, 31 Jan 2023 00:44:38 +0900 Message-Id: <20230130154438.1373750-1-syoshida@redhat.com> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756463045492734405?= X-GMAIL-MSGID: =?utf-8?q?1756463045492734405?= |
Series |
l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register()
|
|
Commit Message
Shigeru Yoshida
Jan. 30, 2023, 3:44 p.m. UTC
When a file descriptor of pppol2tp socket is passed as file descriptor
of UDP socket, a recursive deadlock occurs in l2tp_tunnel_register().
This situation is reproduced by the following program:
int main(void)
{
int sock;
struct sockaddr_pppol2tp addr;
sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);
if (sock < 0) {
perror("socket");
return 1;
}
addr.sa_family = AF_PPPOX;
addr.sa_protocol = PX_PROTO_OL2TP;
addr.pppol2tp.pid = 0;
addr.pppol2tp.fd = sock;
addr.pppol2tp.addr.sin_family = PF_INET;
addr.pppol2tp.addr.sin_port = htons(0);
addr.pppol2tp.addr.sin_addr.s_addr = inet_addr("192.168.0.1");
addr.pppol2tp.s_tunnel = 1;
addr.pppol2tp.s_session = 0;
addr.pppol2tp.d_tunnel = 0;
addr.pppol2tp.d_session = 0;
if (connect(sock, (const struct sockaddr *)&addr, sizeof(addr)) < 0) {
perror("connect");
return 1;
}
return 0;
}
This program causes the following lockdep warning:
============================================
WARNING: possible recursive locking detected
6.2.0-rc5-00205-gc96618275234 #56 Not tainted
--------------------------------------------
repro/8607 is trying to acquire lock:
ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: l2tp_tunnel_register+0x2b7/0x11c0
but task is already holding lock:
ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_PPPOX);
lock(sk_lock-AF_PPPOX);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by repro/8607:
#0: ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30
stack backtrace:
CPU: 0 PID: 8607 Comm: repro Not tainted 6.2.0-rc5-00205-gc96618275234 #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x100/0x178
__lock_acquire.cold+0x119/0x3b9
? lockdep_hardirqs_on_prepare+0x410/0x410
lock_acquire+0x1e0/0x610
? l2tp_tunnel_register+0x2b7/0x11c0
? lock_downgrade+0x710/0x710
? __fget_files+0x283/0x3e0
lock_sock_nested+0x3a/0xf0
? l2tp_tunnel_register+0x2b7/0x11c0
l2tp_tunnel_register+0x2b7/0x11c0
? sprintf+0xc4/0x100
? l2tp_tunnel_del_work+0x6b0/0x6b0
? debug_object_deactivate+0x320/0x320
? lockdep_init_map_type+0x16d/0x7a0
? lockdep_init_map_type+0x16d/0x7a0
? l2tp_tunnel_create+0x2bf/0x4b0
? l2tp_tunnel_create+0x3c6/0x4b0
pppol2tp_connect+0x14e1/0x1a30
? pppol2tp_put_sk+0xd0/0xd0
? aa_sk_perm+0x2b7/0xa80
? aa_af_perm+0x260/0x260
? bpf_lsm_socket_connect+0x9/0x10
? pppol2tp_put_sk+0xd0/0xd0
__sys_connect_file+0x14f/0x190
__sys_connect+0x133/0x160
? __sys_connect_file+0x190/0x190
? lockdep_hardirqs_on+0x7d/0x100
? ktime_get_coarse_real_ts64+0x1b7/0x200
? ktime_get_coarse_real_ts64+0x147/0x200
? __audit_syscall_entry+0x396/0x500
__x64_sys_connect+0x72/0xb0
do_syscall_64+0x38/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
This patch fixes the issue by returning error when a pppol2tp socket
itself is passed.
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
---
net/l2tp/l2tp_ppp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On Tue, Jan 31, 2023 at 12:44:38AM +0900, Shigeru Yoshida wrote: > This patch fixes the issue by returning error when a pppol2tp socket > itself is passed. Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()") > Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> > --- > net/l2tp/l2tp_ppp.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c > index db2e584c625e..88d1a339500b 100644 > --- a/net/l2tp/l2tp_ppp.c > +++ b/net/l2tp/l2tp_ppp.c > @@ -702,11 +702,14 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr, > struct l2tp_tunnel_cfg tcfg = { > .encap = L2TP_ENCAPTYPE_UDP, > }; > + int dummy = 0; There's no need to initialise dummy here. This is just confusing. We could even do without any extra variable and reuse error in sockfd_lookup(). > /* Prevent l2tp_tunnel_register() from trying to set up > - * a kernel socket. > + * a kernel socket. Also, prevent l2tp_tunnel_register() > + * from trying to use pppol2tp socket itself. > */ > - if (info.fd < 0) { > + if (info.fd < 0 || > + sock == sockfd_lookup(info.fd, &dummy)) { > error = -EBADF; > goto end; > } That should work, but the real problem is calling l2tp_tunnel_register() under lock_sock(). We should instead get/create the tunnel before locking the pppol2tp socket.
Hi Guillaume, On Mon, Jan 30, 2023 at 06:03:52PM +0100, Guillaume Nault wrote: > On Tue, Jan 31, 2023 at 12:44:38AM +0900, Shigeru Yoshida wrote: > > This patch fixes the issue by returning error when a pppol2tp socket > > itself is passed. > > Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()") > > > Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> > > --- > > net/l2tp/l2tp_ppp.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c > > index db2e584c625e..88d1a339500b 100644 > > --- a/net/l2tp/l2tp_ppp.c > > +++ b/net/l2tp/l2tp_ppp.c > > @@ -702,11 +702,14 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr, > > struct l2tp_tunnel_cfg tcfg = { > > .encap = L2TP_ENCAPTYPE_UDP, > > }; > > + int dummy = 0; > > There's no need to initialise dummy here. This is just confusing. > We could even do without any extra variable and reuse error in > sockfd_lookup(). > > > /* Prevent l2tp_tunnel_register() from trying to set up > > - * a kernel socket. > > + * a kernel socket. Also, prevent l2tp_tunnel_register() > > + * from trying to use pppol2tp socket itself. > > */ > > - if (info.fd < 0) { > > + if (info.fd < 0 || > > + sock == sockfd_lookup(info.fd, &dummy)) { > > error = -EBADF; > > goto end; > > } > > That should work, but the real problem is calling l2tp_tunnel_register() > under lock_sock(). We should instead get/create the tunnel before > locking the pppol2tp socket. Thank you so much for your comment, and sorry for the late response. Do you mean we can call l2tp_tunnel_register() without pppol2tp socket lock? I've read the source code of pppol2tp_connect(), but I'm not sure why pppol2tp socket is locked at the beginning of this function. If we can call l2tp_tunnel_register() without pppol2tp socket lock, I think we can move lock_sock() after l2tp_tunnel_register(). Thanks, Shigeru >
On Thu, Feb 02, 2023 at 12:43:49AM +0900, Shigeru Yoshida wrote: > Hi Guillaume, > > On Mon, Jan 30, 2023 at 06:03:52PM +0100, Guillaume Nault wrote: > > On Tue, Jan 31, 2023 at 12:44:38AM +0900, Shigeru Yoshida wrote: > > > This patch fixes the issue by returning error when a pppol2tp socket > > > itself is passed. > > > > Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()") > > > > > Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> > > > --- > > > net/l2tp/l2tp_ppp.c | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c > > > index db2e584c625e..88d1a339500b 100644 > > > --- a/net/l2tp/l2tp_ppp.c > > > +++ b/net/l2tp/l2tp_ppp.c > > > @@ -702,11 +702,14 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr, > > > struct l2tp_tunnel_cfg tcfg = { > > > .encap = L2TP_ENCAPTYPE_UDP, > > > }; > > > + int dummy = 0; > > > > There's no need to initialise dummy here. This is just confusing. > > We could even do without any extra variable and reuse error in > > sockfd_lookup(). > > > > > /* Prevent l2tp_tunnel_register() from trying to set up > > > - * a kernel socket. > > > + * a kernel socket. Also, prevent l2tp_tunnel_register() > > > + * from trying to use pppol2tp socket itself. > > > */ > > > - if (info.fd < 0) { > > > + if (info.fd < 0 || > > > + sock == sockfd_lookup(info.fd, &dummy)) { > > > error = -EBADF; > > > goto end; > > > } > > > > That should work, but the real problem is calling l2tp_tunnel_register() > > under lock_sock(). We should instead get/create the tunnel before > > locking the pppol2tp socket. > > Thank you so much for your comment, and sorry for the late response. > > Do you mean we can call l2tp_tunnel_register() without pppol2tp socket > lock? Yes. At this point, we're creating a new tunnel which is independant from the pppol2tp socket. > I've read the source code of pppol2tp_connect(), but I'm not > sure why pppol2tp socket is locked at the beginning of this function. > If we can call l2tp_tunnel_register() without pppol2tp socket lock, I > think we can move lock_sock() after l2tp_tunnel_register(). Here are a few more details to be sure we're on the same page. Locking the pppol2tp socket remains necessary since we access and modify some of its protected attributes. But we can fetch or create the tunnel before working on the socket. For this, the only information we need to get from the socket is its netns. And calling sock_net(sk) without holding the socket lock is fine because user space sockets can't have their netns modified after initialisation. So the code for retrieving or creating the tunnel can be moved before the lock_sock(sk) call in pppol2tp_register(). Just make sure to adjust the error path accordingly. Also, a helper function might help to make the code more readable. > Thanks, > Shigeru > > > >
Hi Guillaume, On Thu, Feb 02, 2023 at 05:43:49PM +0100, Guillaume Nault wrote: > On Thu, Feb 02, 2023 at 12:43:49AM +0900, Shigeru Yoshida wrote: > > Hi Guillaume, > > > > On Mon, Jan 30, 2023 at 06:03:52PM +0100, Guillaume Nault wrote: > > > On Tue, Jan 31, 2023 at 12:44:38AM +0900, Shigeru Yoshida wrote: > > > > This patch fixes the issue by returning error when a pppol2tp socket > > > > itself is passed. > > > > > > Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()") > > > > > > > Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> > > > > --- > > > > net/l2tp/l2tp_ppp.c | 7 +++++-- > > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c > > > > index db2e584c625e..88d1a339500b 100644 > > > > --- a/net/l2tp/l2tp_ppp.c > > > > +++ b/net/l2tp/l2tp_ppp.c > > > > @@ -702,11 +702,14 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr, > > > > struct l2tp_tunnel_cfg tcfg = { > > > > .encap = L2TP_ENCAPTYPE_UDP, > > > > }; > > > > + int dummy = 0; > > > > > > There's no need to initialise dummy here. This is just confusing. > > > We could even do without any extra variable and reuse error in > > > sockfd_lookup(). > > > > > > > /* Prevent l2tp_tunnel_register() from trying to set up > > > > - * a kernel socket. > > > > + * a kernel socket. Also, prevent l2tp_tunnel_register() > > > > + * from trying to use pppol2tp socket itself. > > > > */ > > > > - if (info.fd < 0) { > > > > + if (info.fd < 0 || > > > > + sock == sockfd_lookup(info.fd, &dummy)) { > > > > error = -EBADF; > > > > goto end; > > > > } > > > > > > That should work, but the real problem is calling l2tp_tunnel_register() > > > under lock_sock(). We should instead get/create the tunnel before > > > locking the pppol2tp socket. > > > > Thank you so much for your comment, and sorry for the late response. > > > > Do you mean we can call l2tp_tunnel_register() without pppol2tp socket > > lock? > > Yes. At this point, we're creating a new tunnel which is independant > from the pppol2tp socket. > > > I've read the source code of pppol2tp_connect(), but I'm not > > sure why pppol2tp socket is locked at the beginning of this function. > > If we can call l2tp_tunnel_register() without pppol2tp socket lock, I > > think we can move lock_sock() after l2tp_tunnel_register(). > > Here are a few more details to be sure we're on the same page. > > Locking the pppol2tp socket remains necessary since we access and > modify some of its protected attributes. But we can fetch or create > the tunnel before working on the socket. For this, the only information > we need to get from the socket is its netns. And calling sock_net(sk) > without holding the socket lock is fine because user space sockets > can't have their netns modified after initialisation. > > So the code for retrieving or creating the tunnel can be moved before > the lock_sock(sk) call in pppol2tp_register(). Just make sure to adjust > the error path accordingly. Also, a helper function might help to make > the code more readable. Thank you so much for the detailed explanation. I really appreciate. I'll think about it further, and try to prepare v2 patch. Thanks, Shigeru > > > Thanks, > > Shigeru > > > > > > > >
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c index db2e584c625e..88d1a339500b 100644 --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -702,11 +702,14 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr, struct l2tp_tunnel_cfg tcfg = { .encap = L2TP_ENCAPTYPE_UDP, }; + int dummy = 0; /* Prevent l2tp_tunnel_register() from trying to set up - * a kernel socket. + * a kernel socket. Also, prevent l2tp_tunnel_register() + * from trying to use pppol2tp socket itself. */ - if (info.fd < 0) { + if (info.fd < 0 || + sock == sockfd_lookup(info.fd, &dummy)) { error = -EBADF; goto end; }