diff mbox series

[5.15,015/110] vhost: fix hung thread due to erroneous iotlb entries

Message ID 20220314112743.460512435@linuxfoundation.org
State New
Headers show
Series None | expand

Commit Message

Greg KH March 14, 2022, 11:53 a.m. UTC
From: Anirudh Rayabharam <mail@anirudhrb.com>

[ Upstream commit e2ae38cf3d91837a493cb2093c87700ff3cbe667 ]

In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when
start is 0 and last is ULONG_MAX. One instance where it can happen
is when userspace sends an IOTLB message with iova=size=uaddr=0
(vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,
last = ULONG_MAX ends up in the iotlb. Next time a packet is sent,
iotlb_access_ok() loops indefinitely due to that erroneous entry.

	Call Trace:
	 <TASK>
	 iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
	 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366
	 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104
	 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
	 kthread+0x2e9/0x3a0 kernel/kthread.c:377
	 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
	 </TASK>

Reported by syzbot at:
	https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87

To fix this, do two things:

1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map
   a range with size 0.
2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]
   by splitting it into two entries.

Fixes: 0bbe30668d89e ("vhost: factor out IOTLB")
Reported-by: syzbot+0abd373e2e50d704db87@syzkaller.appspotmail.com
Tested-by: syzbot+0abd373e2e50d704db87@syzkaller.appspotmail.com
Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
Link: https://lore.kernel.org/r/20220305095525.5145-1-mail@anirudhrb.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/vhost/iotlb.c | 11 +++++++++++
 drivers/vhost/vhost.c |  5 +++++
 2 files changed, 16 insertions(+)

Comments

Anirudh Rayabharam March 14, 2022, 4:14 p.m. UTC | #1
Mon, Mar 14, 2022 at 12:53:17PM +0100, Greg Kroah-Hartman wrote:
> From: Anirudh Rayabharam <mail@anirudhrb.com>
> 
> [ Upstream commit e2ae38cf3d91837a493cb2093c87700ff3cbe667 ]

This breaks batching of IOTLB messages. [1] fixes it but hasn't landed in
Linus' tree yet.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/commit/?h=linux-next&id=95932ab2ea07b79cdb33121e2f40ccda9e6a73b5

	- Anirudh.
> 
> In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when
> start is 0 and last is ULONG_MAX. One instance where it can happen
> is when userspace sends an IOTLB message with iova=size=uaddr=0
> (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,
> last = ULONG_MAX ends up in the iotlb. Next time a packet is sent,
> iotlb_access_ok() loops indefinitely due to that erroneous entry.
> 
> 	Call Trace:
> 	 <TASK>
> 	 iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340
> 	 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366
> 	 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104
> 	 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372
> 	 kthread+0x2e9/0x3a0 kernel/kthread.c:377
> 	 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
> 	 </TASK>
> 
> Reported by syzbot at:
> 	https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
> 
> To fix this, do two things:
> 
> 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map
>    a range with size 0.
> 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]
>    by splitting it into two entries.
> 
> Fixes: 0bbe30668d89e ("vhost: factor out IOTLB")
> Reported-by: syzbot+0abd373e2e50d704db87@syzkaller.appspotmail.com
> Tested-by: syzbot+0abd373e2e50d704db87@syzkaller.appspotmail.com
> Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
> Link: https://lore.kernel.org/r/20220305095525.5145-1-mail@anirudhrb.com
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  drivers/vhost/iotlb.c | 11 +++++++++++
>  drivers/vhost/vhost.c |  5 +++++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
> index 670d56c879e5..40b098320b2a 100644
> --- a/drivers/vhost/iotlb.c
> +++ b/drivers/vhost/iotlb.c
> @@ -57,6 +57,17 @@ int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb,
>  	if (last < start)
>  		return -EFAULT;
>  
> +	/* If the range being mapped is [0, ULONG_MAX], split it into two entries
> +	 * otherwise its size would overflow u64.
> +	 */
> +	if (start == 0 && last == ULONG_MAX) {
> +		u64 mid = last / 2;
> +
> +		vhost_iotlb_add_range_ctx(iotlb, start, mid, addr, perm, opaque);
> +		addr += mid + 1;
> +		start = mid + 1;
> +	}
> +
>  	if (iotlb->limit &&
>  	    iotlb->nmaps == iotlb->limit &&
>  	    iotlb->flags & VHOST_IOTLB_FLAG_RETIRE) {
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 59edb5a1ffe2..55475fd59fb7 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1170,6 +1170,11 @@ ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
>  		goto done;
>  	}
>  
> +	if (msg.size == 0) {
> +		ret = -EINVAL;
> +		goto done;
> +	}
> +
>  	if (dev->msg_handler)
>  		ret = dev->msg_handler(dev, &msg);
>  	else
> -- 
> 2.34.1
> 
> 
>
Greg KH March 15, 2022, 9:19 a.m. UTC | #2
On Mon, Mar 14, 2022 at 09:44:43PM +0530, Anirudh Rayabharam wrote:
> Mon, Mar 14, 2022 at 12:53:17PM +0100, Greg Kroah-Hartman wrote:
> > From: Anirudh Rayabharam <mail@anirudhrb.com>
> > 
> > [ Upstream commit e2ae38cf3d91837a493cb2093c87700ff3cbe667 ]
> 
> This breaks batching of IOTLB messages. [1] fixes it but hasn't landed in
> Linus' tree yet.
> 
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/commit/?h=linux-next&id=95932ab2ea07b79cdb33121e2f40ccda9e6a73b5

Why is this tree not in linux-next?  I don't see this commit there, so
how can it get to Linus properly?

thanks,

greg k-h
Michael S. Tsirkin March 15, 2022, 11:50 a.m. UTC | #3
On Tue, Mar 15, 2022 at 10:19:52AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 14, 2022 at 09:44:43PM +0530, Anirudh Rayabharam wrote:
> > Mon, Mar 14, 2022 at 12:53:17PM +0100, Greg Kroah-Hartman wrote:
> > > From: Anirudh Rayabharam <mail@anirudhrb.com>
> > > 
> > > [ Upstream commit e2ae38cf3d91837a493cb2093c87700ff3cbe667 ]
> > 
> > This breaks batching of IOTLB messages. [1] fixes it but hasn't landed in
> > Linus' tree yet.
> > 
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/commit/?h=linux-next&id=95932ab2ea07b79cdb33121e2f40ccda9e6a73b5
> 
> Why is this tree not in linux-next?  I don't see this commit there, so
> how can it get to Linus properly?
> 
> thanks,
> 
> greg k-h

It is in next normally. I was sure this commit was there too. I'm not sure
what happened, maybe I forgot to push :(
Greg KH March 15, 2022, 12:39 p.m. UTC | #4
On Tue, Mar 15, 2022 at 07:50:10AM -0400, Michael S. Tsirkin wrote:
> On Tue, Mar 15, 2022 at 10:19:52AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 14, 2022 at 09:44:43PM +0530, Anirudh Rayabharam wrote:
> > > Mon, Mar 14, 2022 at 12:53:17PM +0100, Greg Kroah-Hartman wrote:
> > > > From: Anirudh Rayabharam <mail@anirudhrb.com>
> > > > 
> > > > [ Upstream commit e2ae38cf3d91837a493cb2093c87700ff3cbe667 ]
> > > 
> > > This breaks batching of IOTLB messages. [1] fixes it but hasn't landed in
> > > Linus' tree yet.
> > > 
> > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/commit/?h=linux-next&id=95932ab2ea07b79cdb33121e2f40ccda9e6a73b5
> > 
> > Why is this tree not in linux-next?  I don't see this commit there, so
> > how can it get to Linus properly?
> > 
> > thanks,
> > 
> > greg k-h
> 
> It is in next normally. I was sure this commit was there too. I'm not sure
> what happened, maybe I forgot to push :(
> 

It's on kernel.org already though.

Anyway, I'll just take it from here directly, thanks.

greg k-h
Michael S. Tsirkin March 15, 2022, 1:30 p.m. UTC | #5
On Tue, Mar 15, 2022 at 01:39:24PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 15, 2022 at 07:50:10AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Mar 15, 2022 at 10:19:52AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 14, 2022 at 09:44:43PM +0530, Anirudh Rayabharam wrote:
> > > > Mon, Mar 14, 2022 at 12:53:17PM +0100, Greg Kroah-Hartman wrote:
> > > > > From: Anirudh Rayabharam <mail@anirudhrb.com>
> > > > > 
> > > > > [ Upstream commit e2ae38cf3d91837a493cb2093c87700ff3cbe667 ]
> > > > 
> > > > This breaks batching of IOTLB messages. [1] fixes it but hasn't landed in
> > > > Linus' tree yet.
> > > > 
> > > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/commit/?h=linux-next&id=95932ab2ea07b79cdb33121e2f40ccda9e6a73b5
> > > 
> > > Why is this tree not in linux-next?  I don't see this commit there, so
> > > how can it get to Linus properly?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > It is in next normally. I was sure this commit was there too. I'm not sure
> > what happened, maybe I forgot to push :(
> > 
> 
> It's on kernel.org already though.
> 
> Anyway, I'll just take it from here directly, thanks.
> 
> greg k-h

Thanks!
diff mbox series

Patch

diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index 670d56c879e5..40b098320b2a 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -57,6 +57,17 @@  int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb,
 	if (last < start)
 		return -EFAULT;
 
+	/* If the range being mapped is [0, ULONG_MAX], split it into two entries
+	 * otherwise its size would overflow u64.
+	 */
+	if (start == 0 && last == ULONG_MAX) {
+		u64 mid = last / 2;
+
+		vhost_iotlb_add_range_ctx(iotlb, start, mid, addr, perm, opaque);
+		addr += mid + 1;
+		start = mid + 1;
+	}
+
 	if (iotlb->limit &&
 	    iotlb->nmaps == iotlb->limit &&
 	    iotlb->flags & VHOST_IOTLB_FLAG_RETIRE) {
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 59edb5a1ffe2..55475fd59fb7 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1170,6 +1170,11 @@  ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
 		goto done;
 	}
 
+	if (msg.size == 0) {
+		ret = -EINVAL;
+		goto done;
+	}
+
 	if (dev->msg_handler)
 		ret = dev->msg_handler(dev, &msg);
 	else