Message-ID: <000000000000b38376059db46aea@google.com>
Date:   Mon, 03 Feb 2020 15:38:13 -0800
From:   syzbot <syzbot+b5ae9f38893979e71173@...kaller.appspotmail.com>
To:     Jason@...c4.com, davem@...emloft.net, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        wireguard@...ts.zx2c4.com
Subject: possible deadlock in peer_remove_after_dead

Hello,

syzbot found the following crash on:

HEAD commit:    754beeec Merge tag 'char-misc-5.6-rc1-2' of git://git.kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14f684e9e00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=99db4e42d047be3
dashboard link: https://syzkaller.appspot.com/bug?extid=b5ae9f38893979e71173
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b5ae9f38893979e71173@...kaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected
5.5.0-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:1/21 is trying to acquire lock:
ffffc90000dd7dc0 ((work_completion)(&peer->transmit_handshake_work)){+.+.}, at: process_one_work+0x917/0x17a0 kernel/workqueue.c:2239

but task is already holding lock:
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: __write_once_size include/linux/compiler.h:226 [inline]
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: atomic64_set include/asm-generic/atomic-instrumented.h:855 [inline]
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: atomic_long_set include/asm-generic/atomic-long.h:40 [inline]
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: set_work_data kernel/workqueue.c:615 [inline]
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: set_work_pool_and_clear_pending kernel/workqueue.c:642 [inline]
ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: process_one_work+0x8dd/0x17a0 kernel/workqueue.c:2235

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 ((wq_completion)wg-kex-wireguard1#2){+.+.}:
       flush_workqueue+0x126/0x14c0 kernel/workqueue.c:2775
       peer_remove_after_dead+0x16b/0x230 drivers/net/wireguard/peer.c:141
       wg_peer_remove+0x244/0x340 drivers/net/wireguard/peer.c:176
       wg_set_device+0xf76/0x1350 drivers/net/wireguard/netlink.c:575
       genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:717 [inline]
       genl_rcv_msg+0x67d/0xea0 net/netlink/genetlink.c:734
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       genl_rcv+0x29/0x40 net/netlink/genetlink.c:745
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:672
       ____sys_sendmsg+0x753/0x880 net/socket.c:2343
       ___sys_sendmsg+0x100/0x170 net/socket.c:2397
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2430
       __do_sys_sendmsg net/socket.c:2439 [inline]
       __se_sys_sendmsg net/socket.c:2437 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2437
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #1 (&wg->static_identity.lock){++++}:
       down_read+0x95/0x430 kernel/locking/rwsem.c:1495
       wg_noise_handshake_create_initiation+0xc0/0x670 drivers/net/wireguard/noise.c:499
       wg_packet_send_handshake_initiation+0x185/0x250 drivers/net/wireguard/send.c:34
       wg_packet_handshake_send_worker+0x1d/0x30 drivers/net/wireguard/send.c:51
       process_one_work+0xa05/0x17a0 kernel/workqueue.c:2264
       worker_thread+0x98/0xe40 kernel/workqueue.c:2410
       kthread+0x361/0x430 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

-> #0 ((work_completion)(&peer->transmit_handshake_work)){+.+.}:
       check_prev_add kernel/locking/lockdep.c:2475 [inline]
       check_prevs_add kernel/locking/lockdep.c:2580 [inline]
       validate_chain kernel/locking/lockdep.c:2970 [inline]
       __lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3954
       lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4484
       process_one_work+0x972/0x17a0 kernel/workqueue.c:2240
       worker_thread+0x98/0xe40 kernel/workqueue.c:2410
       kthread+0x361/0x430 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

other info that might help us debug this:

Chain exists of:
  (work_completion)(&peer->transmit_handshake_work) --> &wg->static_identity.lock --> (wq_completion)wg-kex-wireguard1#2

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((wq_completion)wg-kex-wireguard1#2);
                               lock(&wg->static_identity.lock);
                               lock((wq_completion)wg-kex-wireguard1#2);
  lock((work_completion)(&peer->transmit_handshake_work));

 *** DEADLOCK ***

1 lock held by kworker/u4:1/21:
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: __write_once_size include/linux/compiler.h:226 [inline]
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: atomic64_set include/asm-generic/atomic-instrumented.h:855 [inline]
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: atomic_long_set include/asm-generic/atomic-long.h:40 [inline]
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: set_work_data kernel/workqueue.c:615 [inline]
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: set_work_pool_and_clear_pending kernel/workqueue.c:642 [inline]
 #0: ffff88808fe11528 ((wq_completion)wg-kex-wireguard1#2){+.+.}, at: process_one_work+0x8dd/0x17a0 kernel/workqueue.c:2235

stack backtrace:
CPU: 1 PID: 21 Comm: kworker/u4:1 Not tainted 5.5.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: wg-kex-wireguard1 wg_packet_handshake_send_worker
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x197/0x210 lib/dump_stack.c:118
 print_circular_bug.isra.0.cold+0x163/0x172 kernel/locking/lockdep.c:1684
 check_noncircular+0x32e/0x3e0 kernel/locking/lockdep.c:1808
 check_prev_add kernel/locking/lockdep.c:2475 [inline]
 check_prevs_add kernel/locking/lockdep.c:2580 [inline]
 validate_chain kernel/locking/lockdep.c:2970 [inline]
 __lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3954
 lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4484
 process_one_work+0x972/0x17a0 kernel/workqueue.c:2240
 worker_thread+0x98/0xe40 kernel/workqueue.c:2410
 kthread+0x361/0x430 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based  firewall rule not found. Use the iptables CT target to attach helpers instead.


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@...glegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Powered by blists - more mailing lists