search for: 6b1e6cc7855b0

We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to hold mutexes of all virtqueues. This may confuse lockdep to report a possible deadlock because of trying to hold locks belong to same class. Switch to use mutex_lock_nested() to avoid false positive. Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+dbb7c1161485e61b0241 at syzkaller.appspotmail.com Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vhost.c b/drivers/vho...

We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to hold mutexes of all virtqueues. This may confuse lockdep to report a possible deadlock because of trying to hold locks belong to same class. Switch to use mutex_lock_nested() to avoid false positive. Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+dbb7c1161485e61b0241 at syzkaller.appspotmail.com Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vhost.c b/drivers/vho...

Vq log_base is the userspace address of bitmap which has nothing to do with IOTLB. So it needs to be validated unconditionally otherwise we may try use 0 as log_base which may lead to pin pages that will lead unexpected result (e.g trigger BUG_ON() in set_bit_to_user()). Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+6304bf97ef436580fede at syzkaller.appspotmail.com Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/vhost/vhost....

Vq log_base is the userspace address of bitmap which has nothing to do with IOTLB. So it needs to be validated unconditionally otherwise we may try use 0 as log_base which may lead to pin pages that will lead unexpected result (e.g trigger BUG_ON() in set_bit_to_user()). Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Reported-by: syzbot+6304bf97ef436580fede at syzkaller.appspotmail.com Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/vhost/vhost....

...lean(dev->iotlb); if (!dev->iotlb) { ret = -EFAULT; break; } dev->iotlb = NULL; The reason is we don't synchronize between them, fixing by protecting vhost_process_iotlb_msg() with dev mutex. Reported-by: DaeRyong Jeong <threeearcat at gmail.com> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index f3bd8e9..f0be5f3 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/...

...() in vhost_dev_lock_vqs() which tries to > > hold mutexes of all virtqueues. This may confuse lockdep to report a > > possible deadlock because of trying to hold locks belong to same > > class. Switch to use mutex_lock_nested() to avoid false positive. > > > > Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") > > Reported-by: syzbot+dbb7c1161485e61b0241 at syzkaller.appspotmail.com > > Signed-off-by: Jason Wang <jasowang at redhat.com> > > Michael, I see you ACK'd this, meaning that you're OK with these two > fixes going via m...

...ret = -EFAULT; > break; > } > dev->iotlb = NULL; > > The reason is we don't synchronize between them, fixing by protecting > vhost_process_iotlb_msg() with dev mutex. > > Reported-by: DaeRyong Jeong <threeearcat at gmail.com> > Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") > Reported-by: DaeRyong Jeong <threeearcat at gmail.com> Long terms we might want to move iotlb into vqs so that messages can be processed in parallel. Not sure how to do it yet. > --- > drivers/vhost/vhost.c | 3 +++ > 1 file changed,...

...ret = -EFAULT; > break; > } > dev->iotlb = NULL; > > The reason is we don't synchronize between them, fixing by protecting > vhost_process_iotlb_msg() with dev mutex. > > Reported-by: DaeRyong Jeong <threeearcat at gmail.com> > Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") > Reported-by: DaeRyong Jeong <threeearcat at gmail.com> Long terms we might want to move iotlb into vqs so that messages can be processed in parallel. Not sure how to do it yet. > --- > drivers/vhost/vhost.c | 3 +++ > 1 file changed,...

The code will try to access dev->iotlb when processing VHOST_IOTLB_INVALIDATE even if it was not initialized which may lead to NULL pointer dereference. Fixes this by check dev->iotlb before. Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 549771a..5727b18 100644 --- a/drivers/vhost/vhost.c +++ b/drivers...

...e used to call mutex_lock() in vhost_dev_lock_vqs() which tries to > hold mutexes of all virtqueues. This may confuse lockdep to report a > possible deadlock because of trying to hold locks belong to same > class. Switch to use mutex_lock_nested() to avoid false positive. > > Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") > Reported-by: syzbot+dbb7c1161485e61b0241 at syzkaller.appspotmail.com > Signed-off-by: Jason Wang <jasowang at redhat.com> Michael, I see you ACK'd this, meaning that you're OK with these two fixes going via my net tree? Thanks.

...g_base is the userspace address of bitmap which has nothing to do > with IOTLB. So it needs to be validated unconditionally otherwise we > may try use 0 as log_base which may lead to pin pages that will lead > unexpected result (e.g trigger BUG_ON() in set_bit_to_user()). > > Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") > Reported-by: syzbot+6304bf97ef436580fede at syzkaller.appspotmail.com > Signed-off-by: Jason Wang <jasowang at redhat.com> Acked-by: Michael S. Tsirkin <mst at redhat.com> stable material I guess. > --- > drivers/vhost/vhost.c...

...g_base is the userspace address of bitmap which has nothing to do > with IOTLB. So it needs to be validated unconditionally otherwise we > may try use 0 as log_base which may lead to pin pages that will lead > unexpected result (e.g trigger BUG_ON() in set_bit_to_user()). > > Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") > Reported-by: syzbot+6304bf97ef436580fede at syzkaller.appspotmail.com > Signed-off-by: Jason Wang <jasowang at redhat.com> One follow-up question: We still observe that get user pages returns 0 sometimes. While I agree we should not pass in...

...break; >> } >> dev->iotlb = NULL; >> >> The reason is we don't synchronize between them, fixing by protecting >> vhost_process_iotlb_msg() with dev mutex. >> >> Reported-by: DaeRyong Jeong<threeearcat at gmail.com> >> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") >> Reported-by: DaeRyong Jeong<threeearcat at gmail.com> > Long terms we might want to move iotlb into vqs > so that messages can be processed in parallel. > Not sure how to do it yet. > Then we probably need to extend IOTLB msg to...

On 2018?05?17? 21:45, DaeRyong Jeong wrote: > We report the crash: KASAN: use-after-free Read in vhost_chr_write_iter > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which we describe more at the end of this > report. Our analysis shows that the race occurs when invoking two > syscalls concurrently, write$vnet and

On 2018?05?17? 21:45, DaeRyong Jeong wrote: > We report the crash: KASAN: use-after-free Read in vhost_chr_write_iter > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which we describe more at the end of this > report. Our analysis shows that the race occurs when invoking two > syscalls concurrently, write$vnet and