* net/ipv6: potential deadlock in do_ipv6_setsockopt
@ 2016-10-16 13:34 Baozeng Ding
2016-10-16 18:50 ` Cong Wang
0 siblings, 1 reply; 6+ messages in thread
From: Baozeng Ding @ 2016-10-16 13:34 UTC (permalink / raw)
To: netdev
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
[<ffffffff84ce81d7>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
but task is already holding lock:
([ 165.136033] sk_lock-AF_INET6
[<ffffffff85245db1>] 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] [<ffffffff81427398>] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746
[ 165.136033] [<ffffffff84c54c0b>] lock_sock_nested+0xcb/0x120 net/core/sock.c:2493
[ 165.136033] [<ffffffff85245e28>] do_ipv6_setsockopt.isra.7+0x268/0x2960
[ 165.136033] [<ffffffff852485bb>] ipv6_setsockopt+0x9b/0x140
[ 165.136033] [<ffffffff8525a6c5>] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344
[ 165.136033] [<ffffffff84c4ed85>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688
[ 165.136033] [< inline >] SYSC_setsockopt net/socket.c:1742
[ 165.136033] [<ffffffff84c4bff8>] SyS_setsockopt+0x158/0x240 net/socket.c:1721
[ 165.136033] [<ffffffff85e4d685>] 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] [<ffffffff81424d19>] __lock_acquire+0x35a9/0x4bc0 kernel/locking/lockdep.c:3335
[ 165.136033] [<ffffffff81427398>] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746
[ 165.136033] [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[ 165.136033] [<ffffffff85e44721>] mutex_lock_nested+0xb1/0x860 kernel/locking/mutex.c:621
[ 165.136033] [<ffffffff84ce81d7>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
[ 165.136033] [<ffffffff8528116e>] ipv6_sock_mc_close+0xfe/0x350 net/ipv6/mcast.c:288
[ 165.136033] [<ffffffff85247ebc>] do_ipv6_setsockopt.isra.7+0x22fc/0x2960
[ 165.136033] [<ffffffff852485bb>] ipv6_setsockopt+0x9b/0x140
[ 165.136033] [<ffffffff8525a6c5>] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344
[ 165.136033] [<ffffffff84c4ed85>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688
[ 165.136033] [< inline >] SYSC_setsockopt net/socket.c:1742
[ 165.136033] [<ffffffff84c4bff8>] SyS_setsockopt+0x158/0x240 net/socket.c:1721
[ 165.136033] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
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
ffff880017217580 ffffffff829f835b ffffffff88d65790 ffffffff88d65790
ffffffff88dc6b70 ffff880016f41fd8 ffff8800172175d0 ffffffff8141df18
ffff880016f41ffa dffffc0000000000 000000008764c180 ffff880016f41fd8
Call Trace:
[<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
[<ffffffff8141df18>] 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
[<ffffffff81424d19>] __lock_acquire+0x35a9/0x4bc0 kernel/locking/lockdep.c:3335
[<ffffffff81427398>] lock_acquire+0x1a8/0x380 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffffffff85e44721>] mutex_lock_nested+0xb1/0x860 kernel/locking/mutex.c:621
[<ffffffff84ce81d7>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
[<ffffffff8528116e>] ipv6_sock_mc_close+0xfe/0x350 net/ipv6/mcast.c:288
[<ffffffff85247ebc>] do_ipv6_setsockopt.isra.7+0x22fc/0x2960
[<ffffffff852485bb>] ipv6_setsockopt+0x9b/0x140
[<ffffffff8525a6c5>] udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1344
[<ffffffff84c4ed85>] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2688
[< inline >] SYSC_setsockopt net/socket.c:1742
[<ffffffff84c4bff8>] SyS_setsockopt+0x158/0x240 net/socket.c:1721
[<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
Thanks && Best Regards,
Baozeng Ding
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
2016-10-16 13:34 net/ipv6: potential deadlock in do_ipv6_setsockopt Baozeng Ding
@ 2016-10-16 18:50 ` Cong Wang
2016-10-17 9:54 ` Baozeng Ding
0 siblings, 1 reply; 6+ messages in thread
From: Cong Wang @ 2016-10-16 18:50 UTC (permalink / raw)
To: Baozeng Ding; +Cc: Linux Kernel Network Developers
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Sun, Oct 16, 2016 at 6:34 AM, Baozeng Ding <sploving1@gmail.com> wrote:
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> 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.
[-- Attachment #2: ipv6-setsockopt.diff --]
[-- Type: text/plain, Size: 1379 bytes --]
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,
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
2016-10-16 18:50 ` Cong Wang
@ 2016-10-17 9:54 ` Baozeng Ding
2016-10-19 7:45 ` Baozeng Ding
2016-10-19 13:44 ` Baozeng Ding
0 siblings, 2 replies; 6+ messages in thread
From: Baozeng Ding @ 2016-10-17 9:54 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
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 <sploving1@gmail.com> wrote:
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> 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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
2016-10-17 9:54 ` Baozeng Ding
@ 2016-10-19 7:45 ` Baozeng Ding
2016-10-19 16:36 ` Cong Wang
2016-10-19 13:44 ` Baozeng Ding
1 sibling, 1 reply; 6+ messages in thread
From: Baozeng Ding @ 2016-10-19 7:45 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
It fixes the issue for me.
Tested-by: Baozeng Ding <sploving1@gmail.com>
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 <sploving1@gmail.com> wrote:
>>> Possible unsafe locking scenario:
>>>
>>> CPU0 CPU1
>>> ---- ----
>>> 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.
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
2016-10-17 9:54 ` Baozeng Ding
2016-10-19 7:45 ` Baozeng Ding
@ 2016-10-19 13:44 ` Baozeng Ding
1 sibling, 0 replies; 6+ messages in thread
From: Baozeng Ding @ 2016-10-19 13:44 UTC (permalink / raw)
To: Cong Wang, sploving1; +Cc: Linux Kernel Network Developers
It fixes the issue for me.
Tested-by: Baozeng Ding <sploving1@gmail.com>
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 <sploving1@gmail.com> wrote:
>>> Possible unsafe locking scenario:
>>>
>>> CPU0 CPU1
>>> ---- ----
>>> 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.
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
2016-10-19 7:45 ` Baozeng Ding
@ 2016-10-19 16:36 ` Cong Wang
0 siblings, 0 replies; 6+ messages in thread
From: Cong Wang @ 2016-10-19 16:36 UTC (permalink / raw)
To: Baozeng Ding; +Cc: Linux Kernel Network Developers
On Wed, Oct 19, 2016 at 12:45 AM, Baozeng Ding <sploving1@gmail.com> wrote:
> It fixes the issue for me.
> Tested-by: Baozeng Ding <sploving1@gmail.com>
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-19 16:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-16 13:34 net/ipv6: potential deadlock in do_ipv6_setsockopt Baozeng Ding
2016-10-16 18:50 ` Cong Wang
2016-10-17 9:54 ` Baozeng Ding
2016-10-19 7:45 ` Baozeng Ding
2016-10-19 16:36 ` Cong Wang
2016-10-19 13:44 ` Baozeng Ding
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).