* net/ipv4: deadlock in ip_ra_control
@ 2017-03-01 10:44 Dmitry Vyukov
2017-03-01 17:18 ` Cong Wang
0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Vyukov @ 2017-03-01 10:44 UTC (permalink / raw)
To: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Eric Dumazet, Cong Wang, netdev, LKML
Cc: syzkaller
Hello,
I've got the following deadlock report while running syzkaller fuzzer
on linux-next/51788aebe7cae79cb334ad50641347465fc188fd:
======================================================
[ INFO: possible circular locking dependency detected ]
4.10.0-next-20170301+ #1 Not tainted
-------------------------------------------------------
syz-executor1/3394 is trying to acquire lock:
(sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock
include/net/sock.h:1460 [inline]
(sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>]
do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (rtnl_mutex){+.+.+.}:
validate_chain kernel/locking/lockdep.c:2265 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
__mutex_lock_common kernel/locking/mutex.c:754 [inline]
__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281
ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372
do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161
ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
SYSC_setsockopt net/socket.c:1786 [inline]
SyS_setsockopt+0x25c/0x390 net/socket.c:1765
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #0 (sk_lock-AF_INET){+.+.+.}:
check_prev_add kernel/locking/lockdep.c:1828 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938
validate_chain kernel/locking/lockdep.c:2265 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
lock_sock_nested+0xcb/0x120 net/core/sock.c:2530
lock_sock include/net/sock.h:1460 [inline]
do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
SYSC_setsockopt net/socket.c:1786 [inline]
SyS_setsockopt+0x25c/0x390 net/socket.c:1765
entry_SYSCALL_64_fastpath+0x1f/0xc2
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rtnl_mutex);
lock(sk_lock-AF_INET);
lock(rtnl_mutex);
lock(sk_lock-AF_INET);
*** DEADLOCK ***
1 lock held by syz-executor1/3394:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>]
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
stack backtrace:
CPU: 0 PID: 3394 Comm: syz-executor1 Not tainted 4.10.0-next-20170301+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1202
check_prev_add kernel/locking/lockdep.c:1828 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938
validate_chain kernel/locking/lockdep.c:2265 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
lock_sock_nested+0xcb/0x120 net/core/sock.c:2530
lock_sock include/net/sock.h:1460 [inline]
do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
SYSC_setsockopt net/socket.c:1786 [inline]
SyS_setsockopt+0x25c/0x390 net/socket.c:1765
entry_SYSCALL_64_fastpath+0x1f/0xc2
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: net/ipv4: deadlock in ip_ra_control 2017-03-01 10:44 net/ipv4: deadlock in ip_ra_control Dmitry Vyukov @ 2017-03-01 17:18 ` Cong Wang 2017-03-02 9:40 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Cong Wang @ 2017-03-01 17:18 UTC (permalink / raw) To: Dmitry Vyukov Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller [-- Attachment #1: Type: text/plain, Size: 2869 bytes --] On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote: > Hello, > > I've got the following deadlock report while running syzkaller fuzzer > on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: > > ====================================================== > [ INFO: possible circular locking dependency detected ] > 4.10.0-next-20170301+ #1 Not tainted > ------------------------------------------------------- > syz-executor1/3394 is trying to acquire lock: > (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock > include/net/sock.h:1460 [inline] > (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] > do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 > > but task is already holding lock: > (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20 > net/core/rtnetlink.c:70 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #1 (rtnl_mutex){+.+.+.}: > validate_chain kernel/locking/lockdep.c:2265 [inline] > __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 > lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 > __mutex_lock_common kernel/locking/mutex.c:754 [inline] > __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891 > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906 > rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 > mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281 > ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372 > do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161 > ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 > raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839 > sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 > SYSC_setsockopt net/socket.c:1786 [inline] > SyS_setsockopt+0x25c/0x390 net/socket.c:1765 > entry_SYSCALL_64_fastpath+0x1f/0xc2 > > -> #0 (sk_lock-AF_INET){+.+.+.}: > check_prev_add kernel/locking/lockdep.c:1828 [inline] > check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938 > validate_chain kernel/locking/lockdep.c:2265 [inline] > __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 > lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 > lock_sock_nested+0xcb/0x120 net/core/sock.c:2530 > lock_sock include/net/sock.h:1460 [inline] > do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 > ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 > tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721 > sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 > SYSC_setsockopt net/socket.c:1786 [inline] > SyS_setsockopt+0x25c/0x390 net/socket.c:1765 > entry_SYSCALL_64_fastpath+0x1f/0xc2 > Please try the attached patch (compile only). Thanks. [-- Attachment #2: ip-router-alert.diff --] [-- Type: text/plain, Size: 1627 bytes --] diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c index ebd953b..bda318a 100644 --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -591,6 +591,7 @@ static bool setsockopt_needs_rtnl(int optname) case MCAST_LEAVE_GROUP: case MCAST_LEAVE_SOURCE_GROUP: case MCAST_UNBLOCK_SOURCE: + case IP_ROUTER_ALERT: return true; } return false; diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index beacd02..932321b 100644 --- a/net/ipv4/ipmr.c +++ b/net/ipv4/ipmr.c @@ -1278,7 +1278,7 @@ static void mrtsock_destruct(struct sock *sk) struct net *net = sock_net(sk); struct mr_table *mrt; - rtnl_lock(); + ASSERT_RTNL(); ipmr_for_each_table(mrt, net) { if (sk == rtnl_dereference(mrt->mroute_sk)) { IPV4_DEVCONF_ALL(net, MC_FORWARDING)--; @@ -1289,7 +1289,6 @@ static void mrtsock_destruct(struct sock *sk) mroute_clean_tables(mrt, false); } } - rtnl_unlock(); } /* Socket options and virtual interface manipulation. The whole @@ -1353,13 +1352,8 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, if (sk != rcu_access_pointer(mrt->mroute_sk)) { ret = -EACCES; } else { - /* We need to unlock here because mrtsock_destruct takes - * care of rtnl itself and we can't change that due to - * the IP_ROUTER_ALERT setsockopt which runs without it. - */ - rtnl_unlock(); ret = ip_ra_control(sk, 0, NULL); - goto out; + goto out_unlock; } break; case MRT_ADD_VIF: @@ -1470,7 +1464,6 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, } out_unlock: rtnl_unlock(); -out: return ret; } ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-03-01 17:18 ` Cong Wang @ 2017-03-02 9:40 ` Dmitry Vyukov 2017-03-03 18:43 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Vyukov @ 2017-03-02 9:40 UTC (permalink / raw) To: Cong Wang Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >> Hello, >> >> I've got the following deadlock report while running syzkaller fuzzer >> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: >> >> ====================================================== >> [ INFO: possible circular locking dependency detected ] >> 4.10.0-next-20170301+ #1 Not tainted >> ------------------------------------------------------- >> syz-executor1/3394 is trying to acquire lock: >> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock >> include/net/sock.h:1460 [inline] >> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] >> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >> >> but task is already holding lock: >> (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20 >> net/core/rtnetlink.c:70 >> >> which lock already depends on the new lock. >> >> >> the existing dependency chain (in reverse order) is: >> >> -> #1 (rtnl_mutex){+.+.+.}: >> validate_chain kernel/locking/lockdep.c:2265 [inline] >> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >> __mutex_lock_common kernel/locking/mutex.c:754 [inline] >> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891 >> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906 >> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 >> mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281 >> ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372 >> do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161 >> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >> raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839 >> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >> SYSC_setsockopt net/socket.c:1786 [inline] >> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >> entry_SYSCALL_64_fastpath+0x1f/0xc2 >> >> -> #0 (sk_lock-AF_INET){+.+.+.}: >> check_prev_add kernel/locking/lockdep.c:1828 [inline] >> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938 >> validate_chain kernel/locking/lockdep.c:2265 [inline] >> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >> lock_sock_nested+0xcb/0x120 net/core/sock.c:2530 >> lock_sock include/net/sock.h:1460 [inline] >> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721 >> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >> SYSC_setsockopt net/socket.c:1786 [inline] >> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >> entry_SYSCALL_64_fastpath+0x1f/0xc2 >> > > Please try the attached patch (compile only). Pushed the patch to the bots. Thanks ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-03-02 9:40 ` Dmitry Vyukov @ 2017-03-03 18:43 ` Dmitry Vyukov 2017-03-03 18:45 ` Dmitry Vyukov 2017-03-06 2:04 ` Cong Wang 0 siblings, 2 replies; 9+ messages in thread From: Dmitry Vyukov @ 2017-03-03 18:43 UTC (permalink / raw) To: Cong Wang Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: >> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >>> Hello, >>> >>> I've got the following deadlock report while running syzkaller fuzzer >>> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: >>> >>> ====================================================== >>> [ INFO: possible circular locking dependency detected ] >>> 4.10.0-next-20170301+ #1 Not tainted >>> ------------------------------------------------------- >>> syz-executor1/3394 is trying to acquire lock: >>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock >>> include/net/sock.h:1460 [inline] >>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] >>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>> >>> but task is already holding lock: >>> (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20 >>> net/core/rtnetlink.c:70 >>> >>> which lock already depends on the new lock. >>> >>> >>> the existing dependency chain (in reverse order) is: >>> >>> -> #1 (rtnl_mutex){+.+.+.}: >>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>> __mutex_lock_common kernel/locking/mutex.c:754 [inline] >>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891 >>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906 >>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 >>> mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281 >>> ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372 >>> do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161 >>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>> raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839 >>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>> SYSC_setsockopt net/socket.c:1786 [inline] >>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>> >>> -> #0 (sk_lock-AF_INET){+.+.+.}: >>> check_prev_add kernel/locking/lockdep.c:1828 [inline] >>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938 >>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>> lock_sock_nested+0xcb/0x120 net/core/sock.c:2530 >>> lock_sock include/net/sock.h:1460 [inline] >>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721 >>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>> SYSC_setsockopt net/socket.c:1786 [inline] >>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>> >> >> Please try the attached patch (compile only). > > > Pushed the patch to the bots. > Thanks This patch triggers: [ 57.748990] RTNL: assertion failed at net/ipv4/ipmr.c (1236) [ 57.749022] CPU: 1 PID: 5301 Comm: syz-executor2 Not tainted 4.10.0+ #15 [ 57.749026] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 57.749028] Call Trace: [ 57.749042] dump_stack+0x2ee/0x3ef [ 57.749219] mrtsock_destruct+0x27e/0x2f0 [ 57.749241] ip_ra_control+0x459/0x600 [ 57.749287] raw_close+0x19/0x30 [ 57.749295] inet_release+0xed/0x1c0 [ 57.749303] sock_release+0x8d/0x1e0 [ 57.749316] sock_close+0x16/0x20 [ 57.749323] __fput+0x332/0x7f0 [ 57.749340] ____fput+0x15/0x20 [ 57.749347] task_work_run+0x18a/0x260 [ 57.749372] do_exit+0x18ef/0x28b0 [ 57.749641] do_group_exit+0x149/0x420 [ 57.749656] get_signal+0x7e0/0x1820 [ 57.749697] do_signal+0xd2/0x2190 [ 57.749746] exit_to_usermode_loop+0x200/0x2a0 [ 57.749758] syscall_return_slowpath+0x4d3/0x570 [ 57.749835] entry_SYSCALL_64_fastpath+0xc0/0xc2 [ 57.749840] RIP: 0033:0x44fb79 [ 57.749843] RSP: 002b:00007fbba84d9cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca [ 57.749850] RAX: fffffffffffffe00 RBX: 0000000000708218 RCX: 000000000044fb79 [ 57.749854] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000708218 [ 57.749857] RBP: 00000000007081f8 R08: 0000000000000000 R09: 0000000000000000 [ 57.749860] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 57.749864] R13: 0000000000a5fc57 R14: 00007fbba84da9c0 R15: 000000000000000c [ 57.749964] [ 57.749966] =============================== [ 57.749967] [ INFO: suspicious RCU usage. ] [ 57.749971] 4.10.0+ #15 Not tainted [ 57.749972] ------------------------------- [ 57.749975] net/ipv4/ipmr.c:1238 suspicious rcu_dereference_protected() usage! [ 57.749977] [ 57.749977] other info that might help us debug this: [ 57.749977] [ 57.749980] [ 57.749980] rcu_scheduler_active = 2, debug_locks = 0 [ 57.749982] no locks held by syz-executor2/5301. [ 57.749984] [ 57.749984] stack backtrace: [ 57.749989] CPU: 1 PID: 5301 Comm: syz-executor2 Not tainted 4.10.0+ #15 [ 57.749993] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 57.749995] Call Trace: [ 57.750001] dump_stack+0x2ee/0x3ef [ 57.750117] lockdep_rcu_suspicious+0x139/0x180 [ 57.750122] mrtsock_destruct+0x167/0x2f0 [ 57.750144] ip_ra_control+0x459/0x600 [ 57.750182] raw_close+0x19/0x30 [ 57.750188] inet_release+0xed/0x1c0 [ 57.750194] sock_release+0x8d/0x1e0 [ 57.750208] sock_close+0x16/0x20 [ 57.750213] __fput+0x332/0x7f0 [ 57.750228] ____fput+0x15/0x20 [ 57.750233] task_work_run+0x18a/0x260 [ 57.750256] do_exit+0x18ef/0x28b0 [ 57.750499] do_group_exit+0x149/0x420 [ 57.750515] get_signal+0x7e0/0x1820 [ 57.750556] do_signal+0xd2/0x2190 [ 57.750604] exit_to_usermode_loop+0x200/0x2a0 [ 57.750616] syscall_return_slowpath+0x4d3/0x570 [ 57.750693] entry_SYSCALL_64_fastpath+0xc0/0xc2 [ 57.750698] RIP: 0033:0x44fb79 [ 57.750701] RSP: 002b:00007fbba84d9cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca [ 57.750708] RAX: fffffffffffffe00 RBX: 0000000000708218 RCX: 000000000044fb79 [ 57.750712] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000708218 [ 57.750716] RBP: 00000000007081f8 R08: 0000000000000000 R09: 0000000000000000 [ 57.750720] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 57.750724] R13: 0000000000a5fc57 R14: 00007fbba84da9c0 R15: 000000000000000c ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-03-03 18:43 ` Dmitry Vyukov @ 2017-03-03 18:45 ` Dmitry Vyukov 2017-03-06 2:04 ` Cong Wang 1 sibling, 0 replies; 9+ messages in thread From: Dmitry Vyukov @ 2017-03-03 18:45 UTC (permalink / raw) To: Cong Wang Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller On Fri, Mar 3, 2017 at 7:43 PM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: >>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >>>> Hello, >>>> >>>> I've got the following deadlock report while running syzkaller fuzzer >>>> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: >>>> >>>> ====================================================== >>>> [ INFO: possible circular locking dependency detected ] >>>> 4.10.0-next-20170301+ #1 Not tainted >>>> ------------------------------------------------------- >>>> syz-executor1/3394 is trying to acquire lock: >>>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock >>>> include/net/sock.h:1460 [inline] >>>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] >>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>>> >>>> but task is already holding lock: >>>> (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20 >>>> net/core/rtnetlink.c:70 >>>> >>>> which lock already depends on the new lock. >>>> >>>> >>>> the existing dependency chain (in reverse order) is: >>>> >>>> -> #1 (rtnl_mutex){+.+.+.}: >>>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>>> __mutex_lock_common kernel/locking/mutex.c:754 [inline] >>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891 >>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906 >>>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 >>>> mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281 >>>> ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372 >>>> do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161 >>>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>>> raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839 >>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>>> SYSC_setsockopt net/socket.c:1786 [inline] >>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>>> >>>> -> #0 (sk_lock-AF_INET){+.+.+.}: >>>> check_prev_add kernel/locking/lockdep.c:1828 [inline] >>>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938 >>>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>>> lock_sock_nested+0xcb/0x120 net/core/sock.c:2530 >>>> lock_sock include/net/sock.h:1460 [inline] >>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>>> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721 >>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>>> SYSC_setsockopt net/socket.c:1786 [inline] >>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>>> >>> >>> Please try the attached patch (compile only). >> >> >> Pushed the patch to the bots. >> Thanks > > > This patch triggers: > > [ 57.748990] RTNL: assertion failed at net/ipv4/ipmr.c (1236) > [ 57.749022] CPU: 1 PID: 5301 Comm: syz-executor2 Not tainted 4.10.0+ #15 > [ 57.749026] Hardware name: Google Google Compute Engine/Google > Compute Engine, BIOS Google 01/01/2011 > [ 57.749028] Call Trace: > [ 57.749042] dump_stack+0x2ee/0x3ef > [ 57.749219] mrtsock_destruct+0x27e/0x2f0 > [ 57.749241] ip_ra_control+0x459/0x600 > [ 57.749287] raw_close+0x19/0x30 > [ 57.749295] inet_release+0xed/0x1c0 > [ 57.749303] sock_release+0x8d/0x1e0 > [ 57.749316] sock_close+0x16/0x20 > [ 57.749323] __fput+0x332/0x7f0 > [ 57.749340] ____fput+0x15/0x20 > [ 57.749347] task_work_run+0x18a/0x260 > [ 57.749372] do_exit+0x18ef/0x28b0 > [ 57.749641] do_group_exit+0x149/0x420 > [ 57.749656] get_signal+0x7e0/0x1820 > [ 57.749697] do_signal+0xd2/0x2190 > [ 57.749746] exit_to_usermode_loop+0x200/0x2a0 > [ 57.749758] syscall_return_slowpath+0x4d3/0x570 > [ 57.749835] entry_SYSCALL_64_fastpath+0xc0/0xc2 > [ 57.749840] RIP: 0033:0x44fb79 > [ 57.749843] RSP: 002b:00007fbba84d9cf8 EFLAGS: 00000246 ORIG_RAX: > 00000000000000ca > [ 57.749850] RAX: fffffffffffffe00 RBX: 0000000000708218 RCX: 000000000044fb79 > [ 57.749854] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000708218 > [ 57.749857] RBP: 00000000007081f8 R08: 0000000000000000 R09: 0000000000000000 > [ 57.749860] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > [ 57.749864] R13: 0000000000a5fc57 R14: 00007fbba84da9c0 R15: 000000000000000c > [ 57.749964] > [ 57.749966] =============================== > [ 57.749967] [ INFO: suspicious RCU usage. ] > [ 57.749971] 4.10.0+ #15 Not tainted > [ 57.749972] ------------------------------- > [ 57.749975] net/ipv4/ipmr.c:1238 suspicious > rcu_dereference_protected() usage! > [ 57.749977] > [ 57.749977] other info that might help us debug this: > [ 57.749977] > [ 57.749980] > [ 57.749980] rcu_scheduler_active = 2, debug_locks = 0 > [ 57.749982] no locks held by syz-executor2/5301. > [ 57.749984] > [ 57.749984] stack backtrace: > [ 57.749989] CPU: 1 PID: 5301 Comm: syz-executor2 Not tainted 4.10.0+ #15 > [ 57.749993] Hardware name: Google Google Compute Engine/Google > Compute Engine, BIOS Google 01/01/2011 > [ 57.749995] Call Trace: > [ 57.750001] dump_stack+0x2ee/0x3ef > [ 57.750117] lockdep_rcu_suspicious+0x139/0x180 > [ 57.750122] mrtsock_destruct+0x167/0x2f0 > [ 57.750144] ip_ra_control+0x459/0x600 > [ 57.750182] raw_close+0x19/0x30 > [ 57.750188] inet_release+0xed/0x1c0 > [ 57.750194] sock_release+0x8d/0x1e0 > [ 57.750208] sock_close+0x16/0x20 > [ 57.750213] __fput+0x332/0x7f0 > [ 57.750228] ____fput+0x15/0x20 > [ 57.750233] task_work_run+0x18a/0x260 > [ 57.750256] do_exit+0x18ef/0x28b0 > [ 57.750499] do_group_exit+0x149/0x420 > [ 57.750515] get_signal+0x7e0/0x1820 > [ 57.750556] do_signal+0xd2/0x2190 > [ 57.750604] exit_to_usermode_loop+0x200/0x2a0 > [ 57.750616] syscall_return_slowpath+0x4d3/0x570 > [ 57.750693] entry_SYSCALL_64_fastpath+0xc0/0xc2 > [ 57.750698] RIP: 0033:0x44fb79 > [ 57.750701] RSP: 002b:00007fbba84d9cf8 EFLAGS: 00000246 ORIG_RAX: > 00000000000000ca > [ 57.750708] RAX: fffffffffffffe00 RBX: 0000000000708218 RCX: 000000000044fb79 > [ 57.750712] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000708218 > [ 57.750716] RBP: 00000000007081f8 R08: 0000000000000000 R09: 0000000000000000 > [ 57.750720] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > [ 57.750724] R13: 0000000000a5fc57 R14: 00007fbba84da9c0 R15: 000000000000000c Humm... but only on mmotm (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git auto-latest branch) linux-next and upstream seem to be fine ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-03-03 18:43 ` Dmitry Vyukov 2017-03-03 18:45 ` Dmitry Vyukov @ 2017-03-06 2:04 ` Cong Wang 2017-04-12 12:05 ` Andrey Konovalov 1 sibling, 1 reply; 9+ messages in thread From: Cong Wang @ 2017-03-06 2:04 UTC (permalink / raw) To: Dmitry Vyukov Cc: David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller [-- Attachment #1: Type: text/plain, Size: 3387 bytes --] On Fri, Mar 3, 2017 at 10:43 AM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: >>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >>>> Hello, >>>> >>>> I've got the following deadlock report while running syzkaller fuzzer >>>> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: >>>> >>>> ====================================================== >>>> [ INFO: possible circular locking dependency detected ] >>>> 4.10.0-next-20170301+ #1 Not tainted >>>> ------------------------------------------------------- >>>> syz-executor1/3394 is trying to acquire lock: >>>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock >>>> include/net/sock.h:1460 [inline] >>>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] >>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>>> >>>> but task is already holding lock: >>>> (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20 >>>> net/core/rtnetlink.c:70 >>>> >>>> which lock already depends on the new lock. >>>> >>>> >>>> the existing dependency chain (in reverse order) is: >>>> >>>> -> #1 (rtnl_mutex){+.+.+.}: >>>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>>> __mutex_lock_common kernel/locking/mutex.c:754 [inline] >>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891 >>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906 >>>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 >>>> mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281 >>>> ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372 >>>> do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161 >>>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>>> raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839 >>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>>> SYSC_setsockopt net/socket.c:1786 [inline] >>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>>> >>>> -> #0 (sk_lock-AF_INET){+.+.+.}: >>>> check_prev_add kernel/locking/lockdep.c:1828 [inline] >>>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938 >>>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>>> lock_sock_nested+0xcb/0x120 net/core/sock.c:2530 >>>> lock_sock include/net/sock.h:1460 [inline] >>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>>> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721 >>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>>> SYSC_setsockopt net/socket.c:1786 [inline] >>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>>> >>> >>> Please try the attached patch (compile only). >> >> >> Pushed the patch to the bots. >> Thanks > > > This patch triggers: Ah, update the patch to fix this. [-- Attachment #2: ip-router-alert.diff --] [-- Type: text/plain, Size: 1983 bytes --] diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c index ebd953b..bda318a 100644 --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -591,6 +591,7 @@ static bool setsockopt_needs_rtnl(int optname) case MCAST_LEAVE_GROUP: case MCAST_LEAVE_SOURCE_GROUP: case MCAST_UNBLOCK_SOURCE: + case IP_ROUTER_ALERT: return true; } return false; diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index c0317c9..b036e85 100644 --- a/net/ipv4/ipmr.c +++ b/net/ipv4/ipmr.c @@ -1278,7 +1278,7 @@ static void mrtsock_destruct(struct sock *sk) struct net *net = sock_net(sk); struct mr_table *mrt; - rtnl_lock(); + ASSERT_RTNL(); ipmr_for_each_table(mrt, net) { if (sk == rtnl_dereference(mrt->mroute_sk)) { IPV4_DEVCONF_ALL(net, MC_FORWARDING)--; @@ -1289,7 +1289,6 @@ static void mrtsock_destruct(struct sock *sk) mroute_clean_tables(mrt, false); } } - rtnl_unlock(); } /* Socket options and virtual interface manipulation. The whole @@ -1353,13 +1352,8 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, if (sk != rcu_access_pointer(mrt->mroute_sk)) { ret = -EACCES; } else { - /* We need to unlock here because mrtsock_destruct takes - * care of rtnl itself and we can't change that due to - * the IP_ROUTER_ALERT setsockopt which runs without it. - */ - rtnl_unlock(); ret = ip_ra_control(sk, 0, NULL); - goto out; + goto out_unlock; } break; case MRT_ADD_VIF: @@ -1470,7 +1464,6 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, } out_unlock: rtnl_unlock(); -out: return ret; } diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index 8119e1f..9d94397 100644 --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -682,7 +682,9 @@ static void raw_close(struct sock *sk, long timeout) /* * Raw sockets may have direct kernel references. Kill them. */ + rtnl_lock(); ip_ra_control(sk, 0, NULL); + rtnl_unlock(); sk_common_release(sk); } ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-03-06 2:04 ` Cong Wang @ 2017-04-12 12:05 ` Andrey Konovalov 2017-04-12 19:41 ` Cong Wang 0 siblings, 1 reply; 9+ messages in thread From: Andrey Konovalov @ 2017-04-12 12:05 UTC (permalink / raw) To: Cong Wang Cc: Dmitry Vyukov, David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller [-- Attachment #1: Type: text/plain, Size: 3941 bytes --] On Mon, Mar 6, 2017 at 3:04 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > On Fri, Mar 3, 2017 at 10:43 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >>> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: >>>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov <dvyukov@google.com> wrote: >>>>> Hello, >>>>> >>>>> I've got the following deadlock report while running syzkaller fuzzer >>>>> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd: >>>>> >>>>> ====================================================== >>>>> [ INFO: possible circular locking dependency detected ] >>>>> 4.10.0-next-20170301+ #1 Not tainted >>>>> ------------------------------------------------------- >>>>> syz-executor1/3394 is trying to acquire lock: >>>>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] lock_sock >>>>> include/net/sock.h:1460 [inline] >>>>> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838864cc>] >>>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>>>> >>>>> but task is already holding lock: >>>>> (rtnl_mutex){+.+.+.}, at: [<ffffffff836fbd97>] rtnl_lock+0x17/0x20 >>>>> net/core/rtnetlink.c:70 >>>>> >>>>> which lock already depends on the new lock. >>>>> >>>>> >>>>> the existing dependency chain (in reverse order) is: >>>>> >>>>> -> #1 (rtnl_mutex){+.+.+.}: >>>>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>>>> __mutex_lock_common kernel/locking/mutex.c:754 [inline] >>>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891 >>>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906 >>>>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70 >>>>> mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281 >>>>> ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372 >>>>> do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161 >>>>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>>>> raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839 >>>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>>>> SYSC_setsockopt net/socket.c:1786 [inline] >>>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>>>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>>>> >>>>> -> #0 (sk_lock-AF_INET){+.+.+.}: >>>>> check_prev_add kernel/locking/lockdep.c:1828 [inline] >>>>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938 >>>>> validate_chain kernel/locking/lockdep.c:2265 [inline] >>>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338 >>>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753 >>>>> lock_sock_nested+0xcb/0x120 net/core/sock.c:2530 >>>>> lock_sock include/net/sock.h:1460 [inline] >>>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652 >>>>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264 >>>>> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721 >>>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725 >>>>> SYSC_setsockopt net/socket.c:1786 [inline] >>>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765 >>>>> entry_SYSCALL_64_fastpath+0x1f/0xc2 >>>>> >>>> >>>> Please try the attached patch (compile only). >>> >>> >>> Pushed the patch to the bots. >>> Thanks >> >> >> This patch triggers: > > Ah, update the patch to fix this. Hi Cong, I now have a reproducer for this bug (attached) and your patch fixes it. Could you send it? Thanks! > > -- > You received this message because you are subscribed to the Google Groups "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: ipv4-ra-control-deadlock-poc.c --] [-- Type: text/x-csrc, Size: 6612 bytes --] // autogenerated by syzkaller (http://github.com/google/syzkaller) #ifndef __NR_mmap #define __NR_mmap 9 #endif #ifndef __NR_socket #define __NR_socket 41 #endif #ifndef __NR_setsockopt #define __NR_setsockopt 54 #endif #define _GNU_SOURCE #include <sys/ioctl.h> #include <sys/mman.h> #include <sys/mount.h> #include <sys/prctl.h> #include <sys/resource.h> #include <sys/socket.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/time.h> #include <sys/types.h> #include <sys/wait.h> #include <linux/capability.h> #include <linux/if.h> #include <linux/if_tun.h> #include <linux/kvm.h> #include <linux/sched.h> #include <net/if_arp.h> #include <assert.h> #include <dirent.h> #include <errno.h> #include <fcntl.h> #include <grp.h> #include <pthread.h> #include <setjmp.h> #include <signal.h> #include <stdarg.h> #include <stdbool.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> const int kFailStatus = 67; const int kErrorStatus = 68; const int kRetryStatus = 69; __attribute__((noreturn)) void doexit(int status) { volatile unsigned i; syscall(__NR_exit_group, status); for (i = 0;; i++) { } } __attribute__((noreturn)) void fail(const char* msg, ...) { int e = errno; fflush(stdout); va_list args; va_start(args, msg); vfprintf(stderr, msg, args); va_end(args); fprintf(stderr, " (errno %d)\n", e); doexit((e == ENOMEM || e == EAGAIN) ? kRetryStatus : kFailStatus); } __attribute__((noreturn)) void exitf(const char* msg, ...) { int e = errno; fflush(stdout); va_list args; va_start(args, msg); vfprintf(stderr, msg, args); va_end(args); fprintf(stderr, " (errno %d)\n", e); doexit(kRetryStatus); } static int flag_debug; void debug(const char* msg, ...) { if (!flag_debug) return; va_list args; va_start(args, msg); vfprintf(stdout, msg, args); va_end(args); fflush(stdout); } __thread int skip_segv; __thread jmp_buf segv_env; static void segv_handler(int sig, siginfo_t* info, void* uctx) { uintptr_t addr = (uintptr_t)info->si_addr; const uintptr_t prog_start = 1 << 20; const uintptr_t prog_end = 100 << 20; if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED) && (addr < prog_start || addr > prog_end)) { debug("SIGSEGV on %p, skipping\n", addr); _longjmp(segv_env, 1); } debug("SIGSEGV on %p, exiting\n", addr); doexit(sig); for (;;) { } } static void install_segv_handler() { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_sigaction = segv_handler; sa.sa_flags = SA_NODEFER | SA_SIGINFO; sigaction(SIGSEGV, &sa, NULL); sigaction(SIGBUS, &sa, NULL); } #define NONFAILING(...) \ { \ __atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \ if (_setjmp(segv_env) == 0) { \ __VA_ARGS__; \ } \ __atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \ } #define BITMASK_LEN(type, bf_len) (type)((1ull << (bf_len)) - 1) #define BITMASK_LEN_OFF(type, bf_off, bf_len) \ (type)(BITMASK_LEN(type, (bf_len)) << (bf_off)) #define STORE_BY_BITMASK(type, addr, val, bf_off, bf_len) \ if ((bf_off) == 0 && (bf_len) == 0) { \ *(type*)(addr) = (type)(val); \ } else { \ type new_val = *(type*)(addr); \ new_val &= ~BITMASK_LEN_OFF(type, (bf_off), (bf_len)); \ new_val |= ((type)(val)&BITMASK_LEN(type, (bf_len))) << (bf_off); \ *(type*)(addr) = new_val; \ } static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1, uintptr_t a2, uintptr_t a3, uintptr_t a4, uintptr_t a5, uintptr_t a6, uintptr_t a7, uintptr_t a8) { switch (nr) { default: return syscall(nr, a0, a1, a2, a3, a4, a5); } } static void setup_main_process() { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = SIG_IGN; syscall(SYS_rt_sigaction, 0x20, &sa, NULL, 8); syscall(SYS_rt_sigaction, 0x21, &sa, NULL, 8); install_segv_handler(); char tmpdir_template[] = "./syzkaller.XXXXXX"; char* tmpdir = mkdtemp(tmpdir_template); if (!tmpdir) fail("failed to mkdtemp"); if (chmod(tmpdir, 0777)) fail("failed to chmod"); if (chdir(tmpdir)) fail("failed to chdir"); } static void loop(); static void sandbox_common() { prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0); setpgrp(); setsid(); struct rlimit rlim; rlim.rlim_cur = rlim.rlim_max = 128 << 20; setrlimit(RLIMIT_AS, &rlim); rlim.rlim_cur = rlim.rlim_max = 1 << 20; setrlimit(RLIMIT_FSIZE, &rlim); rlim.rlim_cur = rlim.rlim_max = 1 << 20; setrlimit(RLIMIT_STACK, &rlim); rlim.rlim_cur = rlim.rlim_max = 0; setrlimit(RLIMIT_CORE, &rlim); unshare(CLONE_NEWNS); unshare(CLONE_NEWIPC); unshare(CLONE_IO); } static int do_sandbox_none(int executor_pid, bool enable_tun) { int pid = fork(); if (pid) return pid; sandbox_common(); loop(); doexit(1); } long r[10]; void loop() { memset(r, -1, sizeof(r)); r[0] = execute_syscall(__NR_mmap, 0x20000000ul, 0x4000ul, 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0); r[1] = execute_syscall(__NR_socket, 0x2ul, 0x80003ul, 0x2ul, 0, 0, 0, 0, 0, 0); NONFAILING(*(uint32_t*)0x20f01000 = (uint32_t)0x0); r[3] = execute_syscall(__NR_setsockopt, r[1], 0x0ul, 0xc8ul, 0x20f01000ul, 0x4ul, 0, 0, 0, 0); NONFAILING(*(uint32_t*)0x20001ff4 = (uint32_t)0xa2090000); NONFAILING(*(uint32_t*)0x20001ff8 = (uint32_t)0x0); NONFAILING(*(uint32_t*)0x20001ffc = (uint32_t)0x9); r[7] = execute_syscall(__NR_setsockopt, r[1], 0x0ul, 0x23ul, 0x20001ff4ul, 0xcul, 0, 0, 0, 0); NONFAILING(*(uint32_t*)0x20000000 = (uint32_t)0x0); r[9] = execute_syscall(__NR_setsockopt, r[1], 0x0ul, 0x5ul, 0x20000000ul, 0x4ul, 0, 0, 0, 0); } int main() { setup_main_process(); int pid = do_sandbox_none(0, false); int status = 0; while (waitpid(pid, &status, __WALL) != pid) { } return 0; } ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-04-12 12:05 ` Andrey Konovalov @ 2017-04-12 19:41 ` Cong Wang 2017-04-13 11:58 ` Andrey Konovalov 0 siblings, 1 reply; 9+ messages in thread From: Cong Wang @ 2017-04-12 19:41 UTC (permalink / raw) To: Andrey Konovalov Cc: Dmitry Vyukov, David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller On Wed, Apr 12, 2017 at 5:05 AM, Andrey Konovalov <andreyknvl@google.com> wrote: > Hi Cong, > > I now have a reproducer for this bug (attached) and your patch fixes it. > > Could you send it? > Done. I verified it with your reproducer too. Thanks! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: net/ipv4: deadlock in ip_ra_control 2017-04-12 19:41 ` Cong Wang @ 2017-04-13 11:58 ` Andrey Konovalov 0 siblings, 0 replies; 9+ messages in thread From: Andrey Konovalov @ 2017-04-13 11:58 UTC (permalink / raw) To: Cong Wang Cc: Dmitry Vyukov, David Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet, netdev, LKML, syzkaller On Wed, Apr 12, 2017 at 9:41 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > On Wed, Apr 12, 2017 at 5:05 AM, Andrey Konovalov <andreyknvl@google.com> wrote: >> Hi Cong, >> >> I now have a reproducer for this bug (attached) and your patch fixes it. >> >> Could you send it? >> > > Done. I verified it with your reproducer too. > > Thanks! Great, thanks! ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-04-13 11:58 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-01 10:44 net/ipv4: deadlock in ip_ra_control Dmitry Vyukov 2017-03-01 17:18 ` Cong Wang 2017-03-02 9:40 ` Dmitry Vyukov 2017-03-03 18:43 ` Dmitry Vyukov 2017-03-03 18:45 ` Dmitry Vyukov 2017-03-06 2:04 ` Cong Wang 2017-04-12 12:05 ` Andrey Konovalov 2017-04-12 19:41 ` Cong Wang 2017-04-13 11:58 ` Andrey Konovalov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.