lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 26 Mar 2018 11:48:02 +0800 From: Jason Wang <jasowang@...hat.com> To: syzbot <syzbot+7f073540b1384a614e09@...kaller.appspotmail.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, mst@...hat.com, netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com, virtualization@...ts.linux-foundation.org Subject: Re: possible deadlock in handle_rx On 2018年03月26日 08:01, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > cb6416592bc2a8b731dabcec0d63cda270764fc6 (Sun Mar 25 17:45:10 2018 +0000) > Merge tag 'dmaengine-fix-4.16-rc7' of > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=7f073540b1384a614e09 > > So far this crash happened 4 times on upstream. > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6506789075943424 > syzkaller reproducer: > https://syzkaller.appspot.com/x/repro.syz?id=5716250550337536 > Raw console output: > https://syzkaller.appspot.com/x/log.txt?id=5142038655795200 > Kernel config: > https://syzkaller.appspot.com/x/.config?id=-5034017172441945317 > compiler: gcc (GCC) 7.1.1 20170620 > > IMPORTANT: if you fix the bug, please add the following tag to the > commit: > Reported-by: syzbot+7f073540b1384a614e09@...kaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > > ============================================ > WARNING: possible recursive locking detected > 4.16.0-rc6+ #366 Not tainted > -------------------------------------------- > vhost-4248/4760 is trying to acquire lock: > (&vq->mutex){+.+.}, at: [<000000003482bddc>] > vhost_net_rx_peek_head_len drivers/vhost/net.c:633 [inline] > (&vq->mutex){+.+.}, at: [<000000003482bddc>] handle_rx+0xeb1/0x19c0 > drivers/vhost/net.c:784 > > but task is already holding lock: > (&vq->mutex){+.+.}, at: [<000000004de72f44>] handle_rx+0x1f5/0x19c0 > drivers/vhost/net.c:766 > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&vq->mutex); > lock(&vq->mutex); > > *** DEADLOCK *** > > May be due to missing lock nesting notation Yes, it's a missing of nesting notation. Will post a patch soon. Thanks
Powered by blists - more mailing lists