netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: "David S. Miller\"" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Sitnicki <jakub@cloudflare.com>,
	Tom Parkin <tparkin@katalix.com>
Cc: syzbot <syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com>,
	netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	Haowei Yan <g1042620637@gmail.com>
Subject: [PATCH 6.1-rc6] l2tp: call udp_tunnel_encap_enable() and sock_release() without sk_callback_lock
Date: Fri, 18 Nov 2022 20:51:13 +0900	[thread overview]
Message-ID: <c64284f4-2c2a-ecb9-a08e-9e49d49c720b@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <00000000000011ec5105edb50386@google.com>

syzbot is reporting sleep in atomic context at l2tp_tunnel_register() [1],
for commit b68777d54fac ("l2tp: Serialize access to sk_user_data with
sk_callback_lock") missed that udp_tunnel_encap_enable() from
setup_udp_tunnel_sock() might sleep.

Since we don't want to drop sk->sk_callback_lock inside
setup_udp_tunnel_sock() right before calling udp_tunnel_encap_enable(),
introduce a variant which does not call udp_tunnel_encap_enable(). And
call udp_tunnel_encap_enable() after dropping sk->sk_callback_lock.

Also, drop sk->sk_callback_lock before calling sock_release() in order to
avoid circular locking dependency problem.

Link: https://syzkaller.appspot.com/bug?extid=703d9e154b3b58277261 [1]
Reported-by: syzbot <syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: b68777d54fac ("l2tp: Serialize access to sk_user_data with sk_callback_lock")
---
F.Y.I. Below is the lockdep message:

 ======================================================
 WARNING: possible circular locking dependency detected
 6.1.0-rc5+ #2 Not tainted
 ------------------------------------------------------
 a.out/2794 is trying to acquire lock:
 ffff8c628878bdf0 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x19/0xe0

 but task is already holding lock:
 ffff8c628878c078 (k-clock-AF_INET){+++.}-{2:2}, at: l2tp_tunnel_register+0x64/0x5e0 [l2tp_core]

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #2 (k-clock-AF_INET){+++.}-{2:2}:
        lock_acquire+0xc7/0x2e0
        _raw_read_lock_bh+0x3d/0x80
        sock_i_uid+0x19/0x40
        udp_lib_lport_inuse+0x2c/0x120
        udp_lib_get_port+0xf8/0x570
        udp_v4_get_port+0xbb/0xc0
        __inet_bind+0x10e/0x240
        inet_bind+0x2b/0x40
        kernel_bind+0xb/0x10
        udp_sock_create4+0x97/0x160 [udp_tunnel]
        l2tp_tunnel_sock_create+0x316/0x330 [l2tp_core]
        l2tp_tunnel_register+0x394/0x5e0 [l2tp_core]
        l2tp_nl_cmd_tunnel_create+0xe8/0x200 [l2tp_netlink]
        genl_family_rcv_msg_doit.isra.17+0x102/0x140
        genl_rcv_msg+0x112/0x270
        netlink_rcv_skb+0x4f/0x100
        genl_rcv+0x23/0x40
        netlink_unicast+0x1a5/0x280
        netlink_sendmsg+0x22f/0x490
        sock_sendmsg+0x2e/0x40
        ____sys_sendmsg+0x1e9/0x210
        ___sys_sendmsg+0x77/0xb0
        __sys_sendmsg+0x60/0xb0
        __x64_sys_sendmsg+0x1a/0x20
        do_syscall_64+0x34/0x80
        entry_SYSCALL_64_after_hwframe+0x63/0xcd

 -> #1 (&table->hash[i].lock){+...}-{2:2}:
        lock_acquire+0xc7/0x2e0
        _raw_spin_lock_bh+0x31/0x40
        udp_lib_get_port+0xda/0x570
        udp_v4_get_port+0xbb/0xc0
        __inet_bind+0x10e/0x240
        inet_bind+0x2b/0x40
        kernel_bind+0xb/0x10
        udp_sock_create4+0x97/0x160 [udp_tunnel]
        l2tp_tunnel_sock_create+0x316/0x330 [l2tp_core]
        l2tp_tunnel_register+0x394/0x5e0 [l2tp_core]
        l2tp_nl_cmd_tunnel_create+0xe8/0x200 [l2tp_netlink]
        genl_family_rcv_msg_doit.isra.17+0x102/0x140
        genl_rcv_msg+0x112/0x270
        netlink_rcv_skb+0x4f/0x100
        genl_rcv+0x23/0x40
        netlink_unicast+0x1a5/0x280
        netlink_sendmsg+0x22f/0x490
        sock_sendmsg+0x2e/0x40
        ____sys_sendmsg+0x1e9/0x210
        ___sys_sendmsg+0x77/0xb0
        __sys_sendmsg+0x60/0xb0
        __x64_sys_sendmsg+0x1a/0x20
        do_syscall_64+0x34/0x80
        entry_SYSCALL_64_after_hwframe+0x63/0xcd

 -> #0 (k-sk_lock-AF_INET){+.+.}-{0:0}:
        check_prevs_add+0x16a/0x1070
        __lock_acquire+0x11bd/0x1670
        lock_acquire+0xc7/0x2e0
        udp_destroy_sock+0x2d/0xd0
        sk_common_release+0x19/0xe0
        udp_lib_close+0x9/0x10
        inet_release+0x2e/0x60
        __sock_release+0x7e/0xa0
        sock_release+0xb/0x10
        l2tp_tunnel_register+0x3f1/0x5e0 [l2tp_core]
        l2tp_nl_cmd_tunnel_create+0xe8/0x200 [l2tp_netlink]
        genl_family_rcv_msg_doit.isra.17+0x102/0x140
        genl_rcv_msg+0x112/0x270
        netlink_rcv_skb+0x4f/0x100
        genl_rcv+0x23/0x40
        netlink_unicast+0x1a5/0x280
        netlink_sendmsg+0x22f/0x490
        sock_sendmsg+0x2e/0x40
        ____sys_sendmsg+0x1e9/0x210
        ___sys_sendmsg+0x77/0xb0
        __sys_sendmsg+0x60/0xb0
        __x64_sys_sendmsg+0x1a/0x20
        do_syscall_64+0x34/0x80
        entry_SYSCALL_64_after_hwframe+0x63/0xcd

 other info that might help us debug this:

 Chain exists of:
   k-sk_lock-AF_INET --> &table->hash[i].lock --> k-clock-AF_INET

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(k-clock-AF_INET);
                                lock(&table->hash[i].lock);
                                lock(k-clock-AF_INET);
   lock(k-sk_lock-AF_INET);

  *** DEADLOCK ***

 3 locks held by a.out/2794:
  #0: ffffffffb466fc30 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40
  #1: ffffffffb466fcc8 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0x14d/0x270
  #2: ffff8c628878c078 (k-clock-AF_INET){+++.}-{2:2}, at: l2tp_tunnel_register+0x64/0x5e0 [l2tp_core]

 include/net/udp_tunnel.h   |  2 ++
 net/ipv4/udp_tunnel_core.c | 10 ++++++++--
 net/l2tp/l2tp_core.c       | 10 +++++-----
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
index 72394f441dad..a84fa57bc750 100644
--- a/include/net/udp_tunnel.h
+++ b/include/net/udp_tunnel.h
@@ -92,6 +92,8 @@ struct udp_tunnel_sock_cfg {
 /* Setup the given (UDP) sock to receive UDP encapsulated packets */
 void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
 			   struct udp_tunnel_sock_cfg *sock_cfg);
+void setup_udp_tunnel_sock_no_enable(struct net *net, struct socket *sock,
+				     struct udp_tunnel_sock_cfg *sock_cfg);
 
 /* -- List of parsable UDP tunnel types --
  *
diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c
index 8242c8947340..dff825664000 100644
--- a/net/ipv4/udp_tunnel_core.c
+++ b/net/ipv4/udp_tunnel_core.c
@@ -57,8 +57,8 @@ int udp_sock_create4(struct net *net, struct udp_port_cfg *cfg,
 }
 EXPORT_SYMBOL(udp_sock_create4);
 
-void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
-			   struct udp_tunnel_sock_cfg *cfg)
+void setup_udp_tunnel_sock_no_enable(struct net *net, struct socket *sock,
+				     struct udp_tunnel_sock_cfg *cfg)
 {
 	struct sock *sk = sock->sk;
 
@@ -77,7 +77,13 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
 	udp_sk(sk)->encap_destroy = cfg->encap_destroy;
 	udp_sk(sk)->gro_receive = cfg->gro_receive;
 	udp_sk(sk)->gro_complete = cfg->gro_complete;
+}
+EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock_no_enable);
 
+void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
+			   struct udp_tunnel_sock_cfg *cfg)
+{
+	setup_udp_tunnel_sock_no_enable(net, sock, cfg);
 	udp_tunnel_encap_enable(sock);
 }
 EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock);
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 754fdda8a5f5..a4f611196c83 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1506,7 +1506,7 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
 			.encap_destroy = l2tp_udp_encap_destroy,
 		};
 
-		setup_udp_tunnel_sock(net, sock, &udp_cfg);
+		setup_udp_tunnel_sock_no_enable(net, sock, &udp_cfg);
 	} else {
 		rcu_assign_sk_user_data(sk, tunnel);
 	}
@@ -1519,19 +1519,19 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
 
 	trace_register_tunnel(tunnel);
 
+	write_unlock(&sk->sk_callback_lock);
+	if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+		udp_tunnel_encap_enable(sock);
 	if (tunnel->fd >= 0)
 		sockfd_put(sock);
-
-	write_unlock(&sk->sk_callback_lock);
 	return 0;
 
 err_sock:
+	write_unlock(&sk->sk_callback_lock);
 	if (tunnel->fd < 0)
 		sock_release(sock);
 	else
 		sockfd_put(sock);
-
-	write_unlock(&sk->sk_callback_lock);
 err:
 	return ret;
 }
-- 
2.18.4



  reply	other threads:[~2022-11-18 11:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17  9:55 [syzbot] BUG: sleeping function called from invalid context in static_key_slow_inc syzbot
2022-11-17 12:03 ` syzbot
2022-11-18  1:56 ` syzbot
2022-11-18 11:51   ` Tetsuo Handa [this message]
2022-11-18 12:36     ` [PATCH 6.1-rc6] l2tp: call udp_tunnel_encap_enable() and sock_release() without sk_callback_lock Eric Dumazet
2022-11-18 13:19       ` Tetsuo Handa
2022-11-18 15:04         ` Eric Dumazet
2022-11-18 17:50       ` Jakub Sitnicki
2022-11-19 10:08         ` Tetsuo Handa
2022-11-19 13:13           ` Jakub Sitnicki
     [not found]       ` <a2199ab7c03e71af3ac791e119e52c94e9f023f56c8b0d8014dd70aceee2784e@mu>
2022-11-18 22:10         ` Jakub Sitnicki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c64284f4-2c2a-ecb9-a08e-9e49d49c720b@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=g1042620637@gmail.com \
    --cc=jakub@cloudflare.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tparkin@katalix.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).