Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
On Wed, Oct 19, 2016 at 12:45 AM, Baozeng Ding wrote: > It fixes the issue for me. > Tested-by: Baozeng Ding Thanks for testing, I will send out the patch formally very soon. BTW, you can check mailing archive to see if your email succeeds or not, for example, http://marc.info/?l=linux-netdev
Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
It fixes the issue for me. Tested-by: Baozeng Ding On 2016/10/17 17:54, Baozeng Ding wrote: > Applied the patch to my test tree. I will tell you the result a few days > later. Thank you. > > On 2016/10/17 2:50, Cong Wang wrote: >> On Sun, Oct 16, 2016 at 6:34 AM, Baozeng Ding wrote: >>> Possible unsafe locking scenario: >>> >>>CPU0CPU1 >>> >>> lock([ 165.136033] sk_lock-AF_INET6 >>> ); >>>lock([ 165.136033] rtnl_mutex >>> ); >>>lock([ 165.136033] sk_lock-AF_INET6 >>> ); >>> lock([ 165.136033] rtnl_mutex >>> ); >>> >>> *** DEADLOCK *** >> >> This is caused by the conditional rtnl locking in do_ipv6_setsockopt(). >> It looks like we miss the case of IPV6_ADDRFORM. >> >> Please try the attached patch. >>
Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
It fixes the issue for me. Tested-by: Baozeng Ding On 2016/10/17 17:54, Baozeng Ding wrote: > Applied the patch to my test tree. I will tell you the result a few days > later. Thank you. > > On 2016/10/17 2:50, Cong Wang wrote: >> On Sun, Oct 16, 2016 at 6:34 AM, Baozeng Ding wrote: >>> Possible unsafe locking scenario: >>> >>>CPU0CPU1 >>> >>> lock([ 165.136033] sk_lock-AF_INET6 >>> ); >>>lock([ 165.136033] rtnl_mutex >>> ); >>>lock([ 165.136033] sk_lock-AF_INET6 >>> ); >>> lock([ 165.136033] rtnl_mutex >>> ); >>> >>> *** DEADLOCK *** >> >> This is caused by the conditional rtnl locking in do_ipv6_setsockopt(). >> It looks like we miss the case of IPV6_ADDRFORM. >> >> Please try the attached patch. >>
Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
Applied the patch to my test tree. I will tell you the result a few days later. Thank you. On 2016/10/17 2:50, Cong Wang wrote: > On Sun, Oct 16, 2016 at 6:34 AM, Baozeng Ding wrote: >> Possible unsafe locking scenario: >> >>CPU0CPU1 >> >> lock([ 165.136033] sk_lock-AF_INET6 >> ); >>lock([ 165.136033] rtnl_mutex >> ); >>lock([ 165.136033] sk_lock-AF_INET6 >> ); >> lock([ 165.136033] rtnl_mutex >> ); >> >> *** DEADLOCK *** > > This is caused by the conditional rtnl locking in do_ipv6_setsockopt(). > It looks like we miss the case of IPV6_ADDRFORM. > > Please try the attached patch. >
Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
On Sun, Oct 16, 2016 at 6:34 AM, Baozeng Ding wrote: > Possible unsafe locking scenario: > >CPU0CPU1 > > lock([ 165.136033] sk_lock-AF_INET6 > ); >lock([ 165.136033] rtnl_mutex > ); >lock([ 165.136033] sk_lock-AF_INET6 > ); > lock([ 165.136033] rtnl_mutex > ); > > *** DEADLOCK *** This is caused by the conditional rtnl locking in do_ipv6_setsockopt(). It looks like we miss the case of IPV6_ADDRFORM. Please try the attached patch. diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c index 46ad699..b8c8d20 100644 --- a/net/ipv6/af_inet6.c +++ b/net/ipv6/af_inet6.c @@ -414,7 +414,9 @@ int inet6_release(struct socket *sock) return -EINVAL; /* Free mc lists */ + rtnl_lock(); ipv6_sock_mc_close(sk); + rtnl_unlock(); /* Free ac lists */ ipv6_sock_ac_close(sk); diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c index 5330262..1e4bcce 100644 --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -120,6 +120,7 @@ struct ipv6_txoptions *ipv6_update_options(struct sock *sk, static bool setsockopt_needs_rtnl(int optname) { switch (optname) { + case IPV6_ADDRFORM: case IPV6_ADD_MEMBERSHIP: case IPV6_DROP_MEMBERSHIP: case IPV6_JOIN_ANYCAST: diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index 75c1fc5..41badfd 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -282,10 +282,11 @@ void ipv6_sock_mc_close(struct sock *sk) struct ipv6_mc_socklist *mc_lst; struct net *net = sock_net(sk); + ASSERT_RTNL(); + if (!rcu_access_pointer(np->ipv6_mc_list)) return; - rtnl_lock(); while ((mc_lst = rtnl_dereference(np->ipv6_mc_list)) != NULL) { struct net_device *dev; @@ -305,7 +306,6 @@ void ipv6_sock_mc_close(struct sock *sk) kfree_rcu(mc_lst, rcu); } - rtnl_unlock(); } int ip6_mc_source(int add, int omode, struct sock *sk,
net/ipv6: potential deadlock in do_ipv6_setsockopt
Hello, While running syzkaller fuzzer I have got the following deadlock report. The kernel version is 4.8.0+ (on Oct 7 commit d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0). Unfortunately I failed to find a reproducer for it. === [ INFO: possible circular locking dependency detected ] 4.8.0+ #39 Not tainted --- syz-executor/21301 is trying to acquire lock: ([ 165.136033] rtnl_mutex [] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 but task is already holding lock: ([ 165.136033] sk_lock-AF_INET6 [] do_ipv6_setsockopt.isra.7+0x1f1/0x2960 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: : [ 165.136033] [] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746 [ 165.136033] [] lock_sock_nested+0xcb/0x120 net/core/sock.c:2493 [ 165.136033] [] do_ipv6_setsockopt.isra.7+0x268/0x2960 [ 165.136033] [] ipv6_setsockopt+0x9b/0x140 [ 165.136033] [] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344 [ 165.136033] [] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688 [ 165.136033] [< inline >] SYSC_setsockopt net/socket.c:1742 [ 165.136033] [] SyS_setsockopt+0x158/0x240 net/socket.c:1721 [ 165.136033] [] entry_SYSCALL_64_fastpath+0x23/0xc6 : [ 165.136033] [< inline >] check_prev_add kernel/locking/lockdep.c:1829 [ 165.136033] [< inline >] check_prevs_add kernel/locking/lockdep.c:1939 [ 165.136033] [< inline >] validate_chain kernel/locking/lockdep.c:2266 [ 165.136033] [] __lock_acquire+0x35a9/0x4bc0 kernel/locking/lockdep.c:3335 [ 165.136033] [] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746 [ 165.136033] [< inline >] __mutex_lock_common kernel/locking/mutex.c:521 [ 165.136033] [] mutex_lock_nested+0xb1/0x860 kernel/locking/mutex.c:621 [ 165.136033] [] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 [ 165.136033] [] ipv6_sock_mc_close+0xfe/0x350 net/ipv6/mcast.c:288 [ 165.136033] [] do_ipv6_setsockopt.isra.7+0x22fc/0x2960 [ 165.136033] [] ipv6_setsockopt+0x9b/0x140 [ 165.136033] [] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344 [ 165.136033] [] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688 [ 165.136033] [< inline >] SYSC_setsockopt net/socket.c:1742 [ 165.136033] [] SyS_setsockopt+0x158/0x240 net/socket.c:1721 [ 165.136033] [] entry_SYSCALL_64_fastpath+0x23/0xc6 other info that might help us debug this: Possible unsafe locking scenario: CPU0CPU1 lock([ 165.136033] sk_lock-AF_INET6 ); lock([ 165.136033] rtnl_mutex ); lock([ 165.136033] sk_lock-AF_INET6 ); lock([ 165.136033] rtnl_mutex ); *** DEADLOCK *** 1 lock held by syz-executor/21301: #0: [ 165.136033] ( stack backtrace: CPU: 1 PID: 21301 Comm: syz-executor Not tainted 4.8.0+ #39 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 880017217580 829f835b 88d65790 88d65790 88dc6b70 880016f41fd8 8800172175d0 8141df18 880016f41ffa dc00 8764c180 880016f41fd8 Call Trace: [] dump_stack+0xb3/0x118 lib/dump_stack.c:15 [] print_circular_bug+0x288/0x340 kernel/locking/lockdep.c:1202 [< inline >] check_prev_add kernel/locking/lockdep.c:1829 [< inline >] check_prevs_add kernel/locking/lockdep.c:1939 [< inline >] validate_chain kernel/locking/lockdep.c:2266 [] __lock_acquire+0x35a9/0x4bc0 kernel/locking/lockdep.c:3335 [] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746 [< inline >] __mutex_lock_common kernel/locking/mutex.c:521 [] mutex_lock_nested+0xb1/0x860 kernel/locking/mutex.c:621 [] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 [] ipv6_sock_mc_close+0xfe/0x350 net/ipv6/mcast.c:288 [] do_ipv6_setsockopt.isra.7+0x22fc/0x2960 [] ipv6_setsockopt+0x9b/0x140 [] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344 [] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688 [< inline >] SYSC_setsockopt net/socket.c:1742 [] SyS_setsockopt+0x158/0x240 net/socket.c:1721 [] entry_SYSCALL_64_fastpath+0x23/0xc6 Thanks && Best Regards, Baozeng Ding