[PATCH 0/1][SRU][D/Unstable] CVE-2018-16880 - vhost_net out-of-bounds write

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 0/1][SRU][D/Unstable] CVE-2018-16880 - vhost_net out-of-bounds write

Tyler Hicks-2
https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-16880.html

 A flaw was found in the Linux kernel's handle_rx() function in the [vhost_net]
 driver. A malicious virtual guest, under specific conditions, can trigger an
 out-of-bounds write in a kmalloc-8 slab on a virtual host which may lead to a
 kernel memory corruption and a system panic. Due to the nature of the flaw,
 privilege escalation cannot be fully ruled out. Versions from v4.16 and newer
 are vulnerable.

This is a clean cherry pick to Disco and Unstable. I've ensured that there are
no new build warnings and smoke tested this patch by boot testing in a VM.

Tyler

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/1][SRU][D/Unstable] vhost: fix OOB in get_rx_bufs()

Tyler Hicks-2
From: Jason Wang <[hidden email]>

After batched used ring updating was introduced in commit e2b3b35eb989
("vhost_net: batch used ring update in rx"). We tend to batch heads in
vq->heads for more than one packet. But the quota passed to
get_rx_bufs() was not correctly limited, which can result a OOB write
in vq->heads.

        headcount = get_rx_bufs(vq, vq->heads + nvq->done_idx,
                    vhost_len, &in, vq_log, &log,
                    likely(mergeable) ? UIO_MAXIOV : 1);

UIO_MAXIOV was still used which is wrong since we could have batched
used in vq->heads, this will cause OOB if the next buffer needs more
than 960 (1024 (UIO_MAXIOV) - 64 (VHOST_NET_BATCH)) heads after we've
batched 64 (VHOST_NET_BATCH) heads:
Acked-by: Stefan Hajnoczi <[hidden email]>

=============================================================================
BUG kmalloc-8k (Tainted: G    B            ): Redzone overwritten
-----------------------------------------------------------------------------

INFO: 0x00000000fd93b7a2-0x00000000f0713384. First byte 0xa9 instead of 0xcc
INFO: Allocated in alloc_pd+0x22/0x60 age=3933677 cpu=2 pid=2674
    kmem_cache_alloc_trace+0xbb/0x140
    alloc_pd+0x22/0x60
    gen8_ppgtt_create+0x11d/0x5f0
    i915_ppgtt_create+0x16/0x80
    i915_gem_create_context+0x248/0x390
    i915_gem_context_create_ioctl+0x4b/0xe0
    drm_ioctl_kernel+0xa5/0xf0
    drm_ioctl+0x2ed/0x3a0
    do_vfs_ioctl+0x9f/0x620
    ksys_ioctl+0x6b/0x80
    __x64_sys_ioctl+0x11/0x20
    do_syscall_64+0x43/0xf0
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
INFO: Slab 0x00000000d13e87af objects=3 used=3 fp=0x          (null) flags=0x200000000010201
INFO: Object 0x0000000003278802 @offset=17064 fp=0x00000000e2e6652b

Fixing this by allocating UIO_MAXIOV + VHOST_NET_BATCH iovs for
vhost-net. This is done through set the limitation through
vhost_dev_init(), then set_owner can allocate the number of iov in a
per device manner.

This fixes CVE-2018-16880.

Fixes: e2b3b35eb989 ("vhost_net: batch used ring update in rx")
Signed-off-by: Jason Wang <[hidden email]>
Signed-off-by: David S. Miller <[hidden email]>

CVE-2018-16880

(cherry picked from commit b46a0bf78ad7b150ef5910da83859f7f5a514ffd)
Signed-off-by: Tyler Hicks <[hidden email]>
---
 drivers/vhost/net.c   | 3 ++-
 drivers/vhost/scsi.c  | 2 +-
 drivers/vhost/vhost.c | 7 ++++---
 drivers/vhost/vhost.h | 4 +++-
 drivers/vhost/vsock.c | 2 +-
 5 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index a86aa65ad66d..39155d7cc894 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1114,7 +1114,8 @@ static int vhost_net_open(struct inode *inode, struct file *f)
  n->vqs[i].rx_ring = NULL;
  vhost_net_buf_init(&n->vqs[i].rxq);
  }
- vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
+ vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX,
+       UIO_MAXIOV + VHOST_NET_BATCH);
 
  vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, EPOLLOUT, dev);
  vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, EPOLLIN, dev);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index e7e3ae13516d..0cfa925be4ec 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1398,7 +1398,7 @@ static int vhost_scsi_open(struct inode *inode, struct file *f)
  vqs[i] = &vs->vqs[i].vq;
  vs->vqs[i].vq.handle_kick = vhost_scsi_handle_kick;
  }
- vhost_dev_init(&vs->dev, vqs, VHOST_SCSI_MAX_VQ);
+ vhost_dev_init(&vs->dev, vqs, VHOST_SCSI_MAX_VQ, UIO_MAXIOV);
 
  vhost_scsi_init_inflight(vs, NULL);
 
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c66fc8308b5e..cf82e7266397 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -390,9 +390,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
  vq->indirect = kmalloc_array(UIO_MAXIOV,
      sizeof(*vq->indirect),
      GFP_KERNEL);
- vq->log = kmalloc_array(UIO_MAXIOV, sizeof(*vq->log),
+ vq->log = kmalloc_array(dev->iov_limit, sizeof(*vq->log),
  GFP_KERNEL);
- vq->heads = kmalloc_array(UIO_MAXIOV, sizeof(*vq->heads),
+ vq->heads = kmalloc_array(dev->iov_limit, sizeof(*vq->heads),
   GFP_KERNEL);
  if (!vq->indirect || !vq->log || !vq->heads)
  goto err_nomem;
@@ -414,7 +414,7 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
 }
 
 void vhost_dev_init(struct vhost_dev *dev,
-    struct vhost_virtqueue **vqs, int nvqs)
+    struct vhost_virtqueue **vqs, int nvqs, int iov_limit)
 {
  struct vhost_virtqueue *vq;
  int i;
@@ -427,6 +427,7 @@ void vhost_dev_init(struct vhost_dev *dev,
  dev->iotlb = NULL;
  dev->mm = NULL;
  dev->worker = NULL;
+ dev->iov_limit = iov_limit;
  init_llist_head(&dev->work_list);
  init_waitqueue_head(&dev->wait);
  INIT_LIST_HEAD(&dev->read_list);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 1b675dad5e05..9490e7ddb340 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -170,9 +170,11 @@ struct vhost_dev {
  struct list_head read_list;
  struct list_head pending_list;
  wait_queue_head_t wait;
+ int iov_limit;
 };
 
-void vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue **vqs, int nvqs);
+void vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue **vqs,
+    int nvqs, int iov_limit);
 long vhost_dev_set_owner(struct vhost_dev *dev);
 bool vhost_dev_has_owner(struct vhost_dev *dev);
 long vhost_dev_check_owner(struct vhost_dev *);
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 64b96f426768..e440f87ae1d6 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -531,7 +531,7 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
  vsock->vqs[VSOCK_VQ_TX].handle_kick = vhost_vsock_handle_tx_kick;
  vsock->vqs[VSOCK_VQ_RX].handle_kick = vhost_vsock_handle_rx_kick;
 
- vhost_dev_init(&vsock->dev, vqs, ARRAY_SIZE(vsock->vqs));
+ vhost_dev_init(&vsock->dev, vqs, ARRAY_SIZE(vsock->vqs), UIO_MAXIOV);
 
  file->private_data = vsock;
  spin_lock_init(&vsock->send_pkt_list_lock);
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED[D] / NAK[Unstable]: [PATCH 0/1][SRU][D/Unstable] CVE-2018-16880 - vhost_net out-of-bounds write

Seth Forshee
In reply to this post by Tyler Hicks-2
On Mon, Feb 04, 2019 at 09:03:35PM +0000, Tyler Hicks wrote:

> https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-16880.html
>
>  A flaw was found in the Linux kernel's handle_rx() function in the [vhost_net]
>  driver. A malicious virtual guest, under specific conditions, can trigger an
>  out-of-bounds write in a kmalloc-8 slab on a virtual host which may lead to a
>  kernel memory corruption and a system panic. Due to the nature of the flaw,
>  privilege escalation cannot be fully ruled out. Versions from v4.16 and newer
>  are vulnerable.
>
> This is a clean cherry pick to Disco and Unstable. I've ensured that there are
> no new build warnings and smoke tested this patch by boot testing in a VM.

Applied to disco/master-next. We've already picked up this fix in
unstable when rebasing to 5.0-rc5. Thanks!

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: APPLIED[D] / NAK[Unstable]: [PATCH 0/1][SRU][D/Unstable] CVE-2018-16880 - vhost_net out-of-bounds write

Tyler Hicks-2
On 2019-02-05 12:50:18, Seth Forshee wrote:

> On Mon, Feb 04, 2019 at 09:03:35PM +0000, Tyler Hicks wrote:
> > https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-16880.html
> >
> >  A flaw was found in the Linux kernel's handle_rx() function in the [vhost_net]
> >  driver. A malicious virtual guest, under specific conditions, can trigger an
> >  out-of-bounds write in a kmalloc-8 slab on a virtual host which may lead to a
> >  kernel memory corruption and a system panic. Due to the nature of the flaw,
> >  privilege escalation cannot be fully ruled out. Versions from v4.16 and newer
> >  are vulnerable.
> >
> > This is a clean cherry pick to Disco and Unstable. I've ensured that there are
> > no new build warnings and smoke tested this patch by boot testing in a VM.
>
> Applied to disco/master-next. We've already picked up this fix in
> unstable when rebasing to 5.0-rc5. Thanks!

Oh, I got confused by the master-next branch of the unstable tree. I now
see that it is lagging behind the master branch.

Tyler

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: APPLIED[D] / NAK[Unstable]: [PATCH 0/1][SRU][D/Unstable] CVE-2018-16880 - vhost_net out-of-bounds write

Seth Forshee
On Tue, Feb 05, 2019 at 12:53:51PM -0600, Tyler Hicks wrote:

> On 2019-02-05 12:50:18, Seth Forshee wrote:
> > On Mon, Feb 04, 2019 at 09:03:35PM +0000, Tyler Hicks wrote:
> > > https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-16880.html
> > >
> > >  A flaw was found in the Linux kernel's handle_rx() function in the [vhost_net]
> > >  driver. A malicious virtual guest, under specific conditions, can trigger an
> > >  out-of-bounds write in a kmalloc-8 slab on a virtual host which may lead to a
> > >  kernel memory corruption and a system panic. Due to the nature of the flaw,
> > >  privilege escalation cannot be fully ruled out. Versions from v4.16 and newer
> > >  are vulnerable.
> > >
> > > This is a clean cherry pick to Disco and Unstable. I've ensured that there are
> > > no new build warnings and smoke tested this patch by boot testing in a VM.
> >
> > Applied to disco/master-next. We've already picked up this fix in
> > unstable when rebasing to 5.0-rc5. Thanks!
>
> Oh, I got confused by the master-next branch of the unstable tree. I now
> see that it is lagging behind the master branch.

Yeah, that got pushed there mistakenly at some point, we don't use a
master-next branch on unstable. I've deleted it to avoid confustion in
the future.

Seth

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team