On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote: > syzbot has bisected this bug to: > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc > Author: Jason Wang <jasowang@xxxxxxxxxx> > Date: Fri May 24 08:12:18 2019 +0000 > > vhost: access vq metadata through kernel virtual address > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=149a8a20600000 > start commit: 6d21a41b Add linux-next specific files for 20190718 > git tree: linux-next > final crash: https://syzkaller.appspot.com/x/report.txt?x=169a8a20600000 > console output: https://syzkaller.appspot.com/x/log.txt?x=129a8a20600000 > kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331 > dashboard link: https://syzkaller.appspot.com/bug?extid=e58112d71f77113ddb7b > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10139e68600000 > > Reported-by: syzbot+e58112d71f77113ddb7b@xxxxxxxxxxxxxxxxxxxxxxxxx > Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual > address") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection OK I poked at this for a bit, I see several things that we need to fix, though I'm not yet sure it's the reason for the failures: 1. mmu_notifier_register shouldn't be called from vhost_vring_set_num_addr That's just a bad hack, in particular I don't think device mutex is taken and so poking at two VQs will corrupt memory. So what to do? How about a per vq notifier? Of course we also have synchronize_rcu in the notifier which is slow and is now going to be called twice. I think call_rcu would be more appropriate here. We then need rcu_barrier on module unload. OTOH if we make pages linear with map then we are good with kfree_rcu which is even nicer. 2. Doesn't map leak after vhost_map_unprefetch? And why does it poke at contents of the map? No one should use it right? 3. notifier unregister happens last in vhost_dev_cleanup, but register happens first. This looks wrong to me. 4. OK so we use the invalidate count to try and detect that some invalidate is in progress. I am not 100% sure why do we care. Assuming we do, uaddr can change between start and end and then the counter can get negative, or generally out of sync. So what to do about all this? I am inclined to say let's just drop the uaddr optimization for now. E.g. kvm invalidates unconditionally. 3 should be fixed independently. -- MST
