diff --git a/0011-net-vmxnet-initialise-local-tx-descriptor.patch b/0011-net-vmxnet-initialise-local-tx-descriptor.patch new file mode 100644 index 0000000..666dcf4 --- /dev/null +++ b/0011-net-vmxnet-initialise-local-tx-descriptor.patch @@ -0,0 +1,30 @@ +From: Li Qiang +Date: Thu, 11 Aug 2016 00:42:20 +0530 +Subject: [PATCH] net: vmxnet: initialise local tx descriptor + +In Vmxnet3 device emulator while processing transmit(tx) queue, +when it reaches end of packet, it calls vmxnet3_complete_packet. +In that local 'txcq_descr' object is not initialised, which could +leak host memory bytes a guest. + +Reported-by: Li Qiang +Signed-off-by: Prasad J Pandit +Reviewed-by: Dmitry Fleytman +Signed-off-by: Jason Wang +(cherry picked from commit fdda170e50b8af062cf5741e12c4fb5e57a2eacf) +--- + hw/net/vmxnet3.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c +index 90f6943..92f6af9 100644 +--- a/hw/net/vmxnet3.c ++++ b/hw/net/vmxnet3.c +@@ -531,6 +531,7 @@ static void vmxnet3_complete_packet(VMXNET3State *s, int qidx, uint32_t tx_ridx) + + VMXNET3_RING_DUMP(VMW_RIPRN, "TXC", qidx, &s->txq_descr[qidx].comp_ring); + ++ memset(&txcq_descr, 0, sizeof(txcq_descr)); + txcq_descr.txdIdx = tx_ridx; + txcq_descr.gen = vmxnet3_ring_curr_gen(&s->txq_descr[qidx].comp_ring); + diff --git a/0012-net-pcnet-check-rx-tx-descriptor-ring-length.patch b/0012-net-pcnet-check-rx-tx-descriptor-ring-length.patch new file mode 100644 index 0000000..3589e7b --- /dev/null +++ b/0012-net-pcnet-check-rx-tx-descriptor-ring-length.patch @@ -0,0 +1,34 @@ +From: Prasad J Pandit +Date: Fri, 30 Sep 2016 00:27:33 +0530 +Subject: [PATCH] net: pcnet: check rx/tx descriptor ring length + +The AMD PC-Net II emulator has set of control and status(CSR) +registers. Of these, CSR76 and CSR78 hold receive and transmit +descriptor ring length respectively. This ring length could range +from 1 to 65535. Setting ring length to zero leads to an infinite +loop in pcnet_rdra_addr() or pcnet_transmit(). Add check to avoid it. + +Reported-by: Li Qiang +Signed-off-by: Prasad J Pandit +Signed-off-by: Jason Wang +(cherry picked from commit 34e29ce754c02bb6b3bdd244fbb85033460feaff) +--- + hw/net/pcnet.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/hw/net/pcnet.c b/hw/net/pcnet.c +index 198a01f..3078de8 100644 +--- a/hw/net/pcnet.c ++++ b/hw/net/pcnet.c +@@ -1429,8 +1429,11 @@ static void pcnet_csr_writew(PCNetState *s, uint32_t rap, uint32_t new_value) + case 47: /* POLLINT */ + case 72: + case 74: ++ break; + case 76: /* RCVRL */ + case 78: /* XMTRL */ ++ val = (val > 0) ? val : 512; ++ break; + case 112: + if (CSR_STOP(s) || CSR_SPND(s)) + break; diff --git a/0013-virtio-gpu-fix-memory-leak-in-virtio_gpu_resource_cr.patch b/0013-virtio-gpu-fix-memory-leak-in-virtio_gpu_resource_cr.patch new file mode 100644 index 0000000..5657112 --- /dev/null +++ b/0013-virtio-gpu-fix-memory-leak-in-virtio_gpu_resource_cr.patch @@ -0,0 +1,32 @@ +From: Li Qiang +Date: Sun, 18 Sep 2016 19:07:11 -0700 +Subject: [PATCH] virtio-gpu: fix memory leak in virtio_gpu_resource_create_2d +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In virtio gpu resource create dispatch, if the pixman format is zero +it doesn't free the resource object allocated previously. Thus leading +a host memory leak issue. This patch avoid this. + +Signed-off-by: Li Qiang +Reviewed-by: Marc-André Lureau +Message-id: 57df486e.8379240a.c3620.ff81@mx.google.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit cb3a0522b694cc5bb6424497b3f828ccd28fd1dd) +--- + hw/display/virtio-gpu.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c +index 7fe6ed8..5b6d17b 100644 +--- a/hw/display/virtio-gpu.c ++++ b/hw/display/virtio-gpu.c +@@ -333,6 +333,7 @@ static void virtio_gpu_resource_create_2d(VirtIOGPU *g, + qemu_log_mask(LOG_GUEST_ERROR, + "%s: host couldn't handle guest format %d\n", + __func__, c2d.format); ++ g_free(res); + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER; + return; + } diff --git a/0014-9pfs-fix-potential-host-memory-leak-in-v9fs_read.patch b/0014-9pfs-fix-potential-host-memory-leak-in-v9fs_read.patch new file mode 100644 index 0000000..3661095 --- /dev/null +++ b/0014-9pfs-fix-potential-host-memory-leak-in-v9fs_read.patch @@ -0,0 +1,36 @@ +From: Li Qiang +Date: Mon, 17 Oct 2016 14:13:58 +0200 +Subject: [PATCH] 9pfs: fix potential host memory leak in v9fs_read + +In 9pfs read dispatch function, it doesn't free two QEMUIOVector +object thus causing potential memory leak. This patch avoid this. + +Signed-off-by: Li Qiang +Signed-off-by: Greg Kurz +(cherry picked from commit e95c9a493a5a8d6f969e86c9f19f80ffe6587e19) +--- + hw/9pfs/9p.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 91a4970..1a9ec7e 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -1813,14 +1813,15 @@ static void v9fs_read(void *opaque) + if (len < 0) { + /* IO error return the error */ + err = len; +- goto out; ++ goto out_free_iovec; + } + } while (count < max_count && len > 0); + err = pdu_marshal(pdu, offset, "d", count); + if (err < 0) { +- goto out; ++ goto out_free_iovec; + } + err += offset + count; ++out_free_iovec: + qemu_iovec_destroy(&qiov); + qemu_iovec_destroy(&qiov_full); + } else if (fidp->fid_type == P9_FID_XATTR) { diff --git a/0015-9pfs-allocate-space-for-guest-originated-empty-strin.patch b/0015-9pfs-allocate-space-for-guest-originated-empty-strin.patch new file mode 100644 index 0000000..0a52067 --- /dev/null +++ b/0015-9pfs-allocate-space-for-guest-originated-empty-strin.patch @@ -0,0 +1,56 @@ +From: Li Qiang +Date: Mon, 17 Oct 2016 14:13:58 +0200 +Subject: [PATCH] 9pfs: allocate space for guest originated empty strings + +If a guest sends an empty string paramater to any 9P operation, the current +code unmarshals it into a V9fsString equal to { .size = 0, .data = NULL }. + +This is unfortunate because it can cause NULL pointer dereference to happen +at various locations in the 9pfs code. And we don't want to check str->data +everywhere we pass it to strcmp() or any other function which expects a +dereferenceable pointer. + +This patch enforces the allocation of genuine C empty strings instead, so +callers don't have to bother. + +Out of all v9fs_iov_vunmarshal() users, only v9fs_xattrwalk() checks if +the returned string is empty. It now uses v9fs_string_size() since +name.data cannot be NULL anymore. + +Signed-off-by: Li Qiang +[groug, rewritten title and changelog, + fix empty string check in v9fs_xattrwalk()] +Signed-off-by: Greg Kurz + +(cherry picked from commit ba42ebb863ab7d40adc79298422ed9596df8f73a) +--- + fsdev/9p-iov-marshal.c | 2 +- + hw/9pfs/9p.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/fsdev/9p-iov-marshal.c b/fsdev/9p-iov-marshal.c +index 663cad5..1d16f8d 100644 +--- a/fsdev/9p-iov-marshal.c ++++ b/fsdev/9p-iov-marshal.c +@@ -125,7 +125,7 @@ ssize_t v9fs_iov_vunmarshal(struct iovec *out_sg, int out_num, size_t offset, + str->data = g_malloc(str->size + 1); + copied = v9fs_unpack(str->data, out_sg, out_num, offset, + str->size); +- if (copied > 0) { ++ if (copied >= 0) { + str->data[str->size] = 0; + } else { + v9fs_string_free(str); +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 1a9ec7e..2b161ed 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -3162,7 +3162,7 @@ static void v9fs_xattrwalk(void *opaque) + goto out; + } + v9fs_path_copy(&xattr_fidp->path, &file_fidp->path); +- if (name.data == NULL) { ++ if (!v9fs_string_size(&name)) { + /* + * listxattr request. Get the size first + */ diff --git a/0016-net-rocker-set-limit-to-DMA-buffer-size.patch b/0016-net-rocker-set-limit-to-DMA-buffer-size.patch new file mode 100644 index 0000000..3973667 --- /dev/null +++ b/0016-net-rocker-set-limit-to-DMA-buffer-size.patch @@ -0,0 +1,33 @@ +From: Prasad J Pandit +Date: Wed, 12 Oct 2016 14:40:55 +0530 +Subject: [PATCH] net: rocker: set limit to DMA buffer size + +Rocker network switch emulator has test registers to help debug +DMA operations. While testing host DMA access, a buffer address +is written to register 'TEST_DMA_ADDR' and its size is written to +register 'TEST_DMA_SIZE'. When performing TEST_DMA_CTRL_INVERT +test, if DMA buffer size was greater than 'INT_MAX', it leads to +an invalid buffer access. Limit the DMA buffer size to avoid it. + +Reported-by: Huawei PSIRT +Signed-off-by: Prasad J Pandit +Reviewed-by: Jiri Pirko +Signed-off-by: Jason Wang +(cherry picked from commit 8caed3d564672e8bc6d2e4c6a35228afd01f4723) +--- + hw/net/rocker/rocker.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c +index 30f2ce4..e9d215a 100644 +--- a/hw/net/rocker/rocker.c ++++ b/hw/net/rocker/rocker.c +@@ -860,7 +860,7 @@ static void rocker_io_writel(void *opaque, hwaddr addr, uint32_t val) + rocker_msix_irq(r, val); + break; + case ROCKER_TEST_DMA_SIZE: +- r->test_dma_size = val; ++ r->test_dma_size = val & 0xFFFF; + break; + case ROCKER_TEST_DMA_ADDR + 4: + r->test_dma_addr = ((uint64_t)val) << 32 | r->lower32; diff --git a/0017-char-serial-check-divider-value-against-baud-base.patch b/0017-char-serial-check-divider-value-against-baud-base.patch new file mode 100644 index 0000000..0ddfddf --- /dev/null +++ b/0017-char-serial-check-divider-value-against-baud-base.patch @@ -0,0 +1,34 @@ +From: Prasad J Pandit +Date: Wed, 12 Oct 2016 11:28:08 +0530 +Subject: [PATCH] char: serial: check divider value against baud base + +16550A UART device uses an oscillator to generate frequencies +(baud base), which decide communication speed. This speed could +be changed by dividing it by a divider. If the divider is +greater than the baud base, speed is set to zero, leading to a +divide by zero error. Add check to avoid it. + +Reported-by: Huawei PSIRT +Signed-off-by: Prasad J Pandit +Message-Id: <1476251888-20238-1-git-send-email-ppandit@redhat.com> +Signed-off-by: Paolo Bonzini +(cherry picked from commit 3592fe0c919cf27a81d8e9f9b4f269553418bb01) +--- + hw/char/serial.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/hw/char/serial.c b/hw/char/serial.c +index 3442f47..eec72b7 100644 +--- a/hw/char/serial.c ++++ b/hw/char/serial.c +@@ -153,8 +153,9 @@ static void serial_update_parameters(SerialState *s) + int speed, parity, data_bits, stop_bits, frame_size; + QEMUSerialSetParams ssp; + +- if (s->divider == 0) ++ if (s->divider == 0 || s->divider > s->baudbase) { + return; ++ } + + /* Start bit. */ + frame_size = 1; diff --git a/0018-audio-intel-hda-check-stream-entry-count-during-tran.patch b/0018-audio-intel-hda-check-stream-entry-count-during-tran.patch new file mode 100644 index 0000000..76d0ec3 --- /dev/null +++ b/0018-audio-intel-hda-check-stream-entry-count-during-tran.patch @@ -0,0 +1,35 @@ +From: Prasad J Pandit +Date: Thu, 20 Oct 2016 13:10:24 +0530 +Subject: [PATCH] audio: intel-hda: check stream entry count during transfer + +Intel HDA emulator uses stream of buffers during DMA data +transfers. Each entry has buffer length and buffer pointer +position, which are used to derive bytes to 'copy'. If this +length and buffer pointer were to be same, 'copy' could be +set to zero(0), leading to an infinite loop. Add check to +avoid it. + +Reported-by: Huawei PSIRT +Signed-off-by: Prasad J Pandit +Reviewed-by: Stefan Hajnoczi +Message-id: 1476949224-6865-1-git-send-email-ppandit@redhat.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 0c0fc2b5fd534786051889459848764edd798050) +--- + hw/audio/intel-hda.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c +index cd95340..537face 100644 +--- a/hw/audio/intel-hda.c ++++ b/hw/audio/intel-hda.c +@@ -416,7 +416,8 @@ static bool intel_hda_xfer(HDACodecDevice *dev, uint32_t stnr, bool output, + } + + left = len; +- while (left > 0) { ++ s = st->bentries; ++ while (left > 0 && s-- > 0) { + copy = left; + if (copy > st->bsize - st->lpib) + copy = st->bsize - st->lpib; diff --git a/0019-timer-a9gtimer-remove-loop-to-auto-increment-compara.patch b/0019-timer-a9gtimer-remove-loop-to-auto-increment-compara.patch new file mode 100644 index 0000000..c30352c --- /dev/null +++ b/0019-timer-a9gtimer-remove-loop-to-auto-increment-compara.patch @@ -0,0 +1,48 @@ +From: Prasad J Pandit +Date: Mon, 24 Oct 2016 16:26:54 +0100 +Subject: [PATCH] timer: a9gtimer: remove loop to auto-increment comparator + +ARM A9MP processor has a peripheral timer with an auto-increment +register, which holds an increment step value. A user could set +this value to zero. When auto-increment control bit is enabled, +it leads to an infinite loop in 'a9_gtimer_update' while +updating comparator value. Remove this loop incrementing the +comparator value. + +Reported-by: Li Qiang +Signed-off-by: Prasad J Pandit +Message-id: 1476733226-11635-1-git-send-email-ppandit@redhat.com +Reviewed-by: Peter Maydell +Signed-off-by: Peter Maydell +(cherry picked from commit 6be8f5e2626e102433e569d9cece2120baf0c879) +--- + hw/timer/a9gtimer.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +diff --git a/hw/timer/a9gtimer.c b/hw/timer/a9gtimer.c +index 772f85f..ce1dc63 100644 +--- a/hw/timer/a9gtimer.c ++++ b/hw/timer/a9gtimer.c +@@ -82,15 +82,15 @@ static void a9_gtimer_update(A9GTimerState *s, bool sync) + if ((s->control & R_CONTROL_TIMER_ENABLE) && + (gtb->control & R_CONTROL_COMP_ENABLE)) { + /* R2p0+, where the compare function is >= */ +- while (gtb->compare < update.new) { ++ if (gtb->compare < update.new) { + DB_PRINT("Compare event happened for CPU %d\n", i); + gtb->status = 1; +- if (gtb->control & R_CONTROL_AUTO_INCREMENT) { +- DB_PRINT("Auto incrementing timer compare by %" PRId32 "\n", +- gtb->inc); +- gtb->compare += gtb->inc; +- } else { +- break; ++ if (gtb->control & R_CONTROL_AUTO_INCREMENT && gtb->inc) { ++ uint64_t inc = ++ QEMU_ALIGN_UP(update.new - gtb->compare, gtb->inc); ++ DB_PRINT("Auto incrementing timer compare by %" ++ PRId64 "\n", inc); ++ gtb->compare += inc; + } + } + cdiff = (int64_t)gtb->compare - (int64_t)update.new + 1; diff --git a/0020-net-eepro100-fix-memory-leak-in-device-uninit.patch b/0020-net-eepro100-fix-memory-leak-in-device-uninit.patch new file mode 100644 index 0000000..ac45dc1 --- /dev/null +++ b/0020-net-eepro100-fix-memory-leak-in-device-uninit.patch @@ -0,0 +1,27 @@ +From: Li Qiang +Date: Sat, 8 Oct 2016 05:07:25 -0700 +Subject: [PATCH] net: eepro100: fix memory leak in device uninit + +The exit dispatch of eepro100 network card device doesn't free +the 's->vmstate' field which was allocated in device realize thus +leading a host memory leak. This patch avoid this. + +Signed-off-by: Li Qiang +Signed-off-by: Jason Wang +(cherry picked from commit 2634ab7fe29b3f75d0865b719caf8f310d634aae) +--- + hw/net/eepro100.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c +index bab4dbf..4bf71f2 100644 +--- a/hw/net/eepro100.c ++++ b/hw/net/eepro100.c +@@ -1843,6 +1843,7 @@ static void pci_nic_uninit(PCIDevice *pci_dev) + EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev); + + vmstate_unregister(&pci_dev->qdev, s->vmstate, s); ++ g_free(s->vmstate); + eeprom93xx_free(&pci_dev->qdev, s->eeprom); + qemu_del_nic(s->nic); + } diff --git a/0021-9pfs-fix-information-leak-in-xattr-read.patch b/0021-9pfs-fix-information-leak-in-xattr-read.patch new file mode 100644 index 0000000..4ea15fd --- /dev/null +++ b/0021-9pfs-fix-information-leak-in-xattr-read.patch @@ -0,0 +1,29 @@ +From: Li Qiang +Date: Mon, 17 Oct 2016 14:13:58 +0200 +Subject: [PATCH] 9pfs: fix information leak in xattr read + +9pfs uses g_malloc() to allocate the xattr memory space, if the guest +reads this memory before writing to it, this will leak host heap memory +to the guest. This patch avoid this. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit eb687602853b4ae656e9236ee4222609f3a6887d) +--- + hw/9pfs/9p.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 2b161ed..0c0645f 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -3270,7 +3270,7 @@ static void v9fs_xattrcreate(void *opaque) + xattr_fidp->fs.xattr.flags = flags; + v9fs_string_init(&xattr_fidp->fs.xattr.name); + v9fs_string_copy(&xattr_fidp->fs.xattr.name, &name); +- xattr_fidp->fs.xattr.value = g_malloc(size); ++ xattr_fidp->fs.xattr.value = g_malloc0(size); + err = offset; + put_fid(pdu, file_fidp); + out_nofid: diff --git a/0022-9pfs-fix-memory-leak-in-v9fs_xattrcreate.patch b/0022-9pfs-fix-memory-leak-in-v9fs_xattrcreate.patch new file mode 100644 index 0000000..96ac1c1 --- /dev/null +++ b/0022-9pfs-fix-memory-leak-in-v9fs_xattrcreate.patch @@ -0,0 +1,32 @@ +From: Li Qiang +Date: Mon, 17 Oct 2016 14:13:58 +0200 +Subject: [PATCH] 9pfs: fix memory leak in v9fs_xattrcreate + +The 'fs.xattr.value' field in V9fsFidState object doesn't consider the +situation that this field has been allocated previously. Every time, it +will be allocated directly. This leads to a host memory leak issue if +the client sends another Txattrcreate message with the same fid number +before the fid from the previous time got clunked. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +[groug, updated the changelog to indicate how the leak can occur] +Signed-off-by: Greg Kurz + +(cherry picked from commit ff55e94d23ae94c8628b0115320157c763eb3e06) +--- + hw/9pfs/9p.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 0c0645f..54554ba 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -3270,6 +3270,7 @@ static void v9fs_xattrcreate(void *opaque) + xattr_fidp->fs.xattr.flags = flags; + v9fs_string_init(&xattr_fidp->fs.xattr.name); + v9fs_string_copy(&xattr_fidp->fs.xattr.name, &name); ++ g_free(xattr_fidp->fs.xattr.value); + xattr_fidp->fs.xattr.value = g_malloc0(size); + err = offset; + put_fid(pdu, file_fidp); diff --git a/0023-9pfs-add-xattrwalk_fid-field-in-V9fsXattr-struct.patch b/0023-9pfs-add-xattrwalk_fid-field-in-V9fsXattr-struct.patch new file mode 100644 index 0000000..a86560d --- /dev/null +++ b/0023-9pfs-add-xattrwalk_fid-field-in-V9fsXattr-struct.patch @@ -0,0 +1,70 @@ +From: Li Qiang +Date: Tue, 1 Nov 2016 12:00:40 +0100 +Subject: [PATCH] 9pfs: add xattrwalk_fid field in V9fsXattr struct + +Currently, 9pfs sets the 'copied_len' field in V9fsXattr +to -1 to tag xattr walk fid. As the 'copied_len' is also +used to account for copied bytes, this may make confusion. This patch +add a bool 'xattrwalk_fid' to tag the xattr walk fid. + +Suggested-by: Greg Kurz +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit dd28fbbc2edc0822965d402d927ce646326d6954) +--- + hw/9pfs/9p.c | 7 ++++--- + hw/9pfs/9p.h | 1 + + 2 files changed, 5 insertions(+), 3 deletions(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 54554ba..ad57123 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -310,7 +310,7 @@ static int v9fs_xattr_fid_clunk(V9fsPDU *pdu, V9fsFidState *fidp) + { + int retval = 0; + +- if (fidp->fs.xattr.copied_len == -1) { ++ if (fidp->fs.xattr.xattrwalk_fid) { + /* getxattr/listxattr fid */ + goto free_value; + } +@@ -3177,7 +3177,7 @@ static void v9fs_xattrwalk(void *opaque) + */ + xattr_fidp->fs.xattr.len = size; + xattr_fidp->fid_type = P9_FID_XATTR; +- xattr_fidp->fs.xattr.copied_len = -1; ++ xattr_fidp->fs.xattr.xattrwalk_fid = true; + if (size) { + xattr_fidp->fs.xattr.value = g_malloc(size); + err = v9fs_co_llistxattr(pdu, &xattr_fidp->path, +@@ -3210,7 +3210,7 @@ static void v9fs_xattrwalk(void *opaque) + */ + xattr_fidp->fs.xattr.len = size; + xattr_fidp->fid_type = P9_FID_XATTR; +- xattr_fidp->fs.xattr.copied_len = -1; ++ xattr_fidp->fs.xattr.xattrwalk_fid = true; + if (size) { + xattr_fidp->fs.xattr.value = g_malloc(size); + err = v9fs_co_lgetxattr(pdu, &xattr_fidp->path, +@@ -3266,6 +3266,7 @@ static void v9fs_xattrcreate(void *opaque) + xattr_fidp = file_fidp; + xattr_fidp->fid_type = P9_FID_XATTR; + xattr_fidp->fs.xattr.copied_len = 0; ++ xattr_fidp->fs.xattr.xattrwalk_fid = false; + xattr_fidp->fs.xattr.len = size; + xattr_fidp->fs.xattr.flags = flags; + v9fs_string_init(&xattr_fidp->fs.xattr.name); +diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h +index a386033..699235d 100644 +--- a/hw/9pfs/9p.h ++++ b/hw/9pfs/9p.h +@@ -164,6 +164,7 @@ typedef struct V9fsXattr + void *value; + V9fsString name; + int flags; ++ bool xattrwalk_fid; + } V9fsXattr; + + typedef struct V9fsDir { diff --git a/0024-9pfs-convert-len-copied_len-field-in-V9fsXattr-to-th.patch b/0024-9pfs-convert-len-copied_len-field-in-V9fsXattr-to-th.patch new file mode 100644 index 0000000..f6a5af4 --- /dev/null +++ b/0024-9pfs-convert-len-copied_len-field-in-V9fsXattr-to-th.patch @@ -0,0 +1,44 @@ +From: Li Qiang +Date: Tue, 1 Nov 2016 12:00:40 +0100 +Subject: [PATCH] 9pfs: convert 'len/copied_len' field in V9fsXattr to the type + of uint64_t + +The 'len' in V9fsXattr comes from the 'size' argument in setxattr() +function in guest. The setxattr() function's declaration is this: + +int setxattr(const char *path, const char *name, + const void *value, size_t size, int flags); + +and 'size' is treated as u64 in linux kernel client code: + +int p9_client_xattrcreate(struct p9_fid *fid, const char *name, + u64 attr_size, int flags) + +So the 'len' should have an type of 'uint64_t'. +The 'copied_len' in V9fsXattr is used to account for copied bytes, it +should also have an type of 'uint64_t'. + +Suggested-by: Greg Kurz +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit 8495f9ad26d398f01e208a53f1a5152483a16084) +--- + hw/9pfs/9p.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h +index 699235d..2067863 100644 +--- a/hw/9pfs/9p.h ++++ b/hw/9pfs/9p.h +@@ -159,8 +159,8 @@ typedef struct V9fsConf + + typedef struct V9fsXattr + { +- int64_t copied_len; +- int64_t len; ++ uint64_t copied_len; ++ uint64_t len; + void *value; + V9fsString name; + int flags; diff --git a/0025-9pfs-fix-integer-overflow-issue-in-xattr-read-write.patch b/0025-9pfs-fix-integer-overflow-issue-in-xattr-read-write.patch new file mode 100644 index 0000000..caac5a8 --- /dev/null +++ b/0025-9pfs-fix-integer-overflow-issue-in-xattr-read-write.patch @@ -0,0 +1,89 @@ +From: Li Qiang +Date: Tue, 1 Nov 2016 12:00:40 +0100 +Subject: [PATCH] 9pfs: fix integer overflow issue in xattr read/write +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The v9fs_xattr_read() and v9fs_xattr_write() are passed a guest +originated offset: they must ensure this offset does not go beyond +the size of the extended attribute that was set in v9fs_xattrcreate(). +Unfortunately, the current code implement these checks with unsafe +calculations on 32 and 64 bit values, which may allow a malicious +guest to cause OOB access anyway. + +Fix this by comparing the offset and the xattr size, which are +both uint64_t, before trying to compute the effective number of bytes +to read or write. + +Suggested-by: Greg Kurz +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Reviewed-By: Guido Günther +Signed-off-by: Greg Kurz +(cherry picked from commit 7e55d65c56a03dcd2c5d7c49d37c5a74b55d4bd6) +--- + hw/9pfs/9p.c | 32 ++++++++++++-------------------- + 1 file changed, 12 insertions(+), 20 deletions(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index ad57123..9c18322 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -1629,20 +1629,17 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, + { + ssize_t err; + size_t offset = 7; +- int read_count; +- int64_t xattr_len; ++ uint64_t read_count; + V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); + VirtQueueElement *elem = v->elems[pdu->idx]; + +- xattr_len = fidp->fs.xattr.len; +- read_count = xattr_len - off; ++ if (fidp->fs.xattr.len < off) { ++ read_count = 0; ++ } else { ++ read_count = fidp->fs.xattr.len - off; ++ } + if (read_count > max_count) { + read_count = max_count; +- } else if (read_count < 0) { +- /* +- * read beyond XATTR value +- */ +- read_count = 0; + } + err = pdu_marshal(pdu, offset, "d", read_count); + if (err < 0) { +@@ -1970,23 +1967,18 @@ static int v9fs_xattr_write(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, + { + int i, to_copy; + ssize_t err = 0; +- int write_count; +- int64_t xattr_len; ++ uint64_t write_count; + size_t offset = 7; + + +- xattr_len = fidp->fs.xattr.len; +- write_count = xattr_len - off; +- if (write_count > count) { +- write_count = count; +- } else if (write_count < 0) { +- /* +- * write beyond XATTR value len specified in +- * xattrcreate +- */ ++ if (fidp->fs.xattr.len < off) { + err = -ENOSPC; + goto out; + } ++ write_count = fidp->fs.xattr.len - off; ++ if (write_count > count) { ++ write_count = count; ++ } + err = pdu_marshal(pdu, offset, "d", write_count); + if (err < 0) { + return err; diff --git a/0026-9pfs-fix-memory-leak-in-v9fs_link.patch b/0026-9pfs-fix-memory-leak-in-v9fs_link.patch new file mode 100644 index 0000000..ed43e9f --- /dev/null +++ b/0026-9pfs-fix-memory-leak-in-v9fs_link.patch @@ -0,0 +1,30 @@ +From: Li Qiang +Date: Mon, 17 Oct 2016 14:13:58 +0200 +Subject: [PATCH] 9pfs: fix memory leak in v9fs_link + +The v9fs_link() function keeps a reference on the source fid object. This +causes a memory leak since the reference never goes down to 0. This patch +fixes the issue. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +[groug, rephrased the changelog] +Signed-off-by: Greg Kurz + +(cherry picked from commit 4c1586787ff43c9acd18a56c12d720e3e6be9f7c) +--- + hw/9pfs/9p.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 9c18322..a4ee24f 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -2396,6 +2396,7 @@ static void v9fs_link(void *opaque) + if (!err) { + err = offset; + } ++ put_fid(pdu, oldfidp); + out: + put_fid(pdu, dfidp); + out_nofid: diff --git a/0027-9pfs-fix-memory-leak-in-v9fs_write.patch b/0027-9pfs-fix-memory-leak-in-v9fs_write.patch new file mode 100644 index 0000000..144590f --- /dev/null +++ b/0027-9pfs-fix-memory-leak-in-v9fs_write.patch @@ -0,0 +1,31 @@ +From: Li Qiang +Date: Mon, 17 Oct 2016 14:13:58 +0200 +Subject: [PATCH] 9pfs: fix memory leak in v9fs_write + +If an error occurs when marshalling the transfer length to the guest, the +v9fs_write() function doesn't free an IO vector, thus leading to a memory +leak. This patch fixes the issue. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +[groug, rephrased the changelog] +Signed-off-by: Greg Kurz + +(cherry picked from commit fdfcc9aeea1492f4b819a24c94dfb678145b1bf9) +--- + hw/9pfs/9p.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index a4ee24f..03a5a35 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -2073,7 +2073,7 @@ static void v9fs_write(void *opaque) + offset = 7; + err = pdu_marshal(pdu, offset, "d", total); + if (err < 0) { +- goto out; ++ goto out_qiov; + } + err += offset; + trace_v9fs_write_return(pdu->tag, pdu->id, total, err); diff --git a/0028-xen-fix-ioreq-handling.patch b/0028-xen-fix-ioreq-handling.patch new file mode 100644 index 0000000..5632b2c --- /dev/null +++ b/0028-xen-fix-ioreq-handling.patch @@ -0,0 +1,71 @@ +From: Jan Beulich +Date: Tue, 22 Nov 2016 05:56:51 -0700 +Subject: [PATCH] xen: fix ioreq handling + +Avoid double fetches and bounds check size to avoid overflowing +internal variables. + +This is CVE-2016-9381 / XSA-197. + +Reported-by: yanghongke +Signed-off-by: Jan Beulich +Reviewed-by: Stefano Stabellini +Signed-off-by: Stefano Stabellini +(cherry picked from commit b85f9dfdb156ae2a2a52f39a36e9f1f270614cd2) +--- + xen-hvm.c | 16 +++++++++++++++- + 1 file changed, 15 insertions(+), 1 deletion(-) + +diff --git a/xen-hvm.c b/xen-hvm.c +index 2f348ed..097007d 100644 +--- a/xen-hvm.c ++++ b/xen-hvm.c +@@ -810,6 +810,10 @@ static void cpu_ioreq_pio(ioreq_t *req) + trace_cpu_ioreq_pio(req, req->dir, req->df, req->data_is_ptr, req->addr, + req->data, req->count, req->size); + ++ if (req->size > sizeof(uint32_t)) { ++ hw_error("PIO: bad size (%u)", req->size); ++ } ++ + if (req->dir == IOREQ_READ) { + if (!req->data_is_ptr) { + req->data = do_inp(req->addr, req->size); +@@ -846,6 +850,10 @@ static void cpu_ioreq_move(ioreq_t *req) + trace_cpu_ioreq_move(req, req->dir, req->df, req->data_is_ptr, req->addr, + req->data, req->count, req->size); + ++ if (req->size > sizeof(req->data)) { ++ hw_error("MMIO: bad size (%u)", req->size); ++ } ++ + if (!req->data_is_ptr) { + if (req->dir == IOREQ_READ) { + for (i = 0; i < req->count; i++) { +@@ -1010,11 +1018,13 @@ static int handle_buffered_iopage(XenIOState *state) + req.df = 1; + req.type = buf_req->type; + req.data_is_ptr = 0; ++ xen_rmb(); + qw = (req.size == 8); + if (qw) { + buf_req = &buf_page->buf_ioreq[(rdptr + 1) % + IOREQ_BUFFER_SLOT_NUM]; + req.data |= ((uint64_t)buf_req->data) << 32; ++ xen_rmb(); + } + + handle_ioreq(state, &req); +@@ -1045,7 +1055,11 @@ static void cpu_handle_ioreq(void *opaque) + + handle_buffered_iopage(state); + if (req) { +- handle_ioreq(state, req); ++ ioreq_t copy = *req; ++ ++ xen_rmb(); ++ handle_ioreq(state, ©); ++ req->data = copy.data; + + if (req->state != STATE_IOREQ_INPROCESS) { + fprintf(stderr, "Badness in I/O request ... not in service?!: " diff --git a/0029-display-cirrus-check-vga-bits-per-pixel-bpp-value.patch b/0029-display-cirrus-check-vga-bits-per-pixel-bpp-value.patch new file mode 100644 index 0000000..37cb998 --- /dev/null +++ b/0029-display-cirrus-check-vga-bits-per-pixel-bpp-value.patch @@ -0,0 +1,73 @@ +From: Prasad J Pandit +Date: Tue, 18 Oct 2016 13:15:17 +0530 +Subject: [PATCH] display: cirrus: check vga bits per pixel(bpp) value + +In Cirrus CLGD 54xx VGA Emulator, if cirrus graphics mode is VGA, +'cirrus_get_bpp' returns zero(0), which could lead to a divide +by zero error in while copying pixel data. The same could occur +via blit pitch values. Add check to avoid it. + +Reported-by: Huawei PSIRT +Signed-off-by: Prasad J Pandit +Message-id: 1476776717-24807-1-git-send-email-ppandit@redhat.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 4299b90e9ba9ce5ca9024572804ba751aa1a7e70) +--- + hw/display/cirrus_vga.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c +index 3d712d5..bdb092e 100644 +--- a/hw/display/cirrus_vga.c ++++ b/hw/display/cirrus_vga.c +@@ -272,6 +272,9 @@ static void cirrus_update_memory_access(CirrusVGAState *s); + static bool blit_region_is_unsafe(struct CirrusVGAState *s, + int32_t pitch, int32_t addr) + { ++ if (!pitch) { ++ return true; ++ } + if (pitch < 0) { + int64_t min = addr + + ((int64_t)s->cirrus_blt_height-1) * pitch; +@@ -715,7 +718,7 @@ static int cirrus_bitblt_videotovideo_patterncopy(CirrusVGAState * s) + s->cirrus_addr_mask)); + } + +-static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) ++static int cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) + { + int sx = 0, sy = 0; + int dx = 0, dy = 0; +@@ -729,6 +732,9 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) + int width, height; + + depth = s->vga.get_bpp(&s->vga) / 8; ++ if (!depth) { ++ return 0; ++ } + s->vga.get_resolution(&s->vga, &width, &height); + + /* extra x, y */ +@@ -783,6 +789,8 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) + cirrus_invalidate_region(s, s->cirrus_blt_dstaddr, + s->cirrus_blt_dstpitch, s->cirrus_blt_width, + s->cirrus_blt_height); ++ ++ return 1; + } + + static int cirrus_bitblt_videotovideo_copy(CirrusVGAState * s) +@@ -790,11 +798,9 @@ static int cirrus_bitblt_videotovideo_copy(CirrusVGAState * s) + if (blit_is_unsafe(s)) + return 0; + +- cirrus_do_copy(s, s->cirrus_blt_dstaddr - s->vga.start_addr, ++ return cirrus_do_copy(s, s->cirrus_blt_dstaddr - s->vga.start_addr, + s->cirrus_blt_srcaddr - s->vga.start_addr, + s->cirrus_blt_width, s->cirrus_blt_height); +- +- return 1; + } + + /*************************************** diff --git a/0030-net-mcf-check-receive-buffer-size-register-value.patch b/0030-net-mcf-check-receive-buffer-size-register-value.patch new file mode 100644 index 0000000..4d29214 --- /dev/null +++ b/0030-net-mcf-check-receive-buffer-size-register-value.patch @@ -0,0 +1,31 @@ +From: Prasad J Pandit +Date: Tue, 29 Nov 2016 00:38:39 +0530 +Subject: [PATCH] net: mcf: check receive buffer size register value + +ColdFire Fast Ethernet Controller uses a receive buffer size +register(EMRBR) to hold maximum size of all receive buffers. +It is set by a user before any operation. If it was set to be +zero, ColdFire emulator would go into an infinite loop while +receiving data in mcf_fec_receive. Add check to avoid it. + +Reported-by: Wjjzhang +Signed-off-by: Prasad J Pandit +Signed-off-by: Jason Wang +(cherry picked from commit 77d54985b85a0cb760330ec2bd92505e0a2a97a9) +--- + hw/net/mcf_fec.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c +index d31fea1..3d4b3b3 100644 +--- a/hw/net/mcf_fec.c ++++ b/hw/net/mcf_fec.c +@@ -393,7 +393,7 @@ static void mcf_fec_write(void *opaque, hwaddr addr, + s->tx_descriptor = s->etdsr; + break; + case 0x188: +- s->emrbr = value & 0x7f0; ++ s->emrbr = value > 0 ? value & 0x7F0 : 0x7F0; + break; + default: + hw_error("mcf_fec_write Bad address 0x%x\n", (int)addr); diff --git a/0031-virtio-gpu-fix-information-leak-in-getting-capset-in.patch b/0031-virtio-gpu-fix-information-leak-in-getting-capset-in.patch new file mode 100644 index 0000000..4b93002 --- /dev/null +++ b/0031-virtio-gpu-fix-information-leak-in-getting-capset-in.patch @@ -0,0 +1,34 @@ +From: Li Qiang +Date: Tue, 1 Nov 2016 02:53:11 -0700 +Subject: [PATCH] virtio-gpu: fix information leak in getting capset info + dispatch +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In virgl_cmd_get_capset_info dispatch function, the 'resp' hasn't +been full initialized before writing to the guest. This will leak +the 'resp.padding' and 'resp.hdr.padding' fieds to the guest. This +patch fix this issue. + +Signed-off-by: Li Qiang +Message-id: 5818661e.0860240a.77264.7a56@mx.google.com +Reviewed-by: Marc-André Lureau +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 42a8dadc74f8982fc269e54e3c5627b54d9f83d8) +--- + hw/display/virtio-gpu-3d.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c +index 758d33a..23f39de 100644 +--- a/hw/display/virtio-gpu-3d.c ++++ b/hw/display/virtio-gpu-3d.c +@@ -347,6 +347,7 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g, + + VIRTIO_GPU_FILL_CMD(info); + ++ memset(&resp, 0, sizeof(resp)); + if (info.capset_index == 0) { + resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL; + virgl_renderer_get_cap_set(resp.capset_id, diff --git a/0032-virtio-gpu-fix-memory-leak-in-update_cursor_data_vir.patch b/0032-virtio-gpu-fix-memory-leak-in-update_cursor_data_vir.patch new file mode 100644 index 0000000..bf9c8ff --- /dev/null +++ b/0032-virtio-gpu-fix-memory-leak-in-update_cursor_data_vir.patch @@ -0,0 +1,33 @@ +From: Li Qiang +Date: Tue, 1 Nov 2016 04:06:58 -0700 +Subject: [PATCH] virtio-gpu: fix memory leak in update_cursor_data_virgl +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In update_cursor_data_virgl function, if the 'width'/ 'height' +is not equal to current cursor's width/height it will return +without free the 'data' allocated previously. This will lead +a memory leak issue. This patch fix this issue. + +Signed-off-by: Li Qiang +Message-id: 58187760.41d71c0a.cca75.4cb9@mx.google.com +Reviewed-by: Marc-André Lureau +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 2d1cd6c7a91a4beb99a0c3a21be529222a708545) +--- + hw/display/virtio-gpu.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c +index 5b6d17b..41f8096 100644 +--- a/hw/display/virtio-gpu.c ++++ b/hw/display/virtio-gpu.c +@@ -84,6 +84,7 @@ static void update_cursor_data_virgl(VirtIOGPU *g, + + if (width != s->current_cursor->width || + height != s->current_cursor->height) { ++ free(data); + return; + } + diff --git a/0033-usbredir-free-vm_change_state_handler-in-usbredir-de.patch b/0033-usbredir-free-vm_change_state_handler-in-usbredir-de.patch new file mode 100644 index 0000000..f8c0aee --- /dev/null +++ b/0033-usbredir-free-vm_change_state_handler-in-usbredir-de.patch @@ -0,0 +1,51 @@ +From: Li Qiang +Date: Mon, 7 Nov 2016 21:57:46 -0800 +Subject: [PATCH] usbredir: free vm_change_state_handler in usbredir destroy + dispatch +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In usbredir destroy dispatch function, it doesn't free the vm change +state handler once registered in usbredir_realize function. This will +lead a memory leak issue. This patch avoid this. + +Signed-off-by: Li Qiang +Reviewed-by: Marc-André Lureau +Message-id: 58216976.d0236b0a.77b99.bcd6@mx.google.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 07b026fd82d6cf11baf7d7c603c4f5f6070b35bf) +--- + hw/usb/redirect.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c +index d4ca026..d064961 100644 +--- a/hw/usb/redirect.c ++++ b/hw/usb/redirect.c +@@ -132,6 +132,7 @@ struct USBRedirDevice { + struct usbredirfilter_rule *filter_rules; + int filter_rules_count; + int compatible_speedmask; ++ VMChangeStateEntry *vmstate; + }; + + #define TYPE_USB_REDIR "usb-redir" +@@ -1409,7 +1410,8 @@ static void usbredir_realize(USBDevice *udev, Error **errp) + qemu_chr_add_handlers(dev->cs, usbredir_chardev_can_read, + usbredir_chardev_read, usbredir_chardev_event, dev); + +- qemu_add_vm_change_state_handler(usbredir_vm_state_change, dev); ++ dev->vmstate = ++ qemu_add_vm_change_state_handler(usbredir_vm_state_change, dev); + } + + static void usbredir_cleanup_device_queues(USBRedirDevice *dev) +@@ -1446,6 +1448,7 @@ static void usbredir_handle_destroy(USBDevice *udev) + } + + free(dev->filter_rules); ++ qemu_del_vm_change_state_handler(dev->vmstate); + } + + static int usbredir_check_filter(USBRedirDevice *dev) diff --git a/0034-usb-ehci-fix-memory-leak-in-ehci_init_transfer.patch b/0034-usb-ehci-fix-memory-leak-in-ehci_init_transfer.patch new file mode 100644 index 0000000..51be7c4 --- /dev/null +++ b/0034-usb-ehci-fix-memory-leak-in-ehci_init_transfer.patch @@ -0,0 +1,28 @@ +From: Li Qiang +Date: Tue, 8 Nov 2016 04:11:10 -0800 +Subject: [PATCH] usb: ehci: fix memory leak in ehci_init_transfer + +In ehci_init_transfer function, if the 'cpage' is bigger than 4, +it doesn't free the 'p->sgl' once allocated previously thus leading +a memory leak issue. This patch avoid this. + +Signed-off-by: Li Qiang +Message-id: 5821c0f4.091c6b0a.e0c92.e811@mx.google.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 791f97758e223de3290592d169f8e6339c281714) +--- + hw/usb/hcd-ehci.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c +index f4ece9a..7622a3a 100644 +--- a/hw/usb/hcd-ehci.c ++++ b/hw/usb/hcd-ehci.c +@@ -1190,6 +1190,7 @@ static int ehci_init_transfer(EHCIPacket *p) + while (bytes > 0) { + if (cpage > 4) { + fprintf(stderr, "cpage out of range (%d)\n", cpage); ++ qemu_sglist_destroy(&p->sgl); + return -1; + } + diff --git a/0035-9pfs-adjust-the-order-of-resource-cleanup-in-device-.patch b/0035-9pfs-adjust-the-order-of-resource-cleanup-in-device-.patch new file mode 100644 index 0000000..529d748 --- /dev/null +++ b/0035-9pfs-adjust-the-order-of-resource-cleanup-in-device-.patch @@ -0,0 +1,40 @@ +From: Li Qiang +Date: Wed, 23 Nov 2016 13:53:34 +0100 +Subject: [PATCH] 9pfs: adjust the order of resource cleanup in device + unrealize + +Unrealize should undo things that were set during realize in +reverse order. So should do in the error path in realize. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit 4774718e5c194026ba5ee7a28d9be49be3080e42) +--- + hw/9pfs/9p.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 03a5a35..1b7dd84 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -3492,8 +3492,8 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp) + rc = 0; + out: + if (rc) { +- g_free(s->ctx.fs_root); + g_free(s->tag); ++ g_free(s->ctx.fs_root); + v9fs_path_free(&path); + } + return rc; +@@ -3501,8 +3501,8 @@ out: + + void v9fs_device_unrealize_common(V9fsState *s, Error **errp) + { +- g_free(s->ctx.fs_root); + g_free(s->tag); ++ g_free(s->ctx.fs_root); + } + + static void __attribute__((__constructor__)) v9fs_set_fd_limit(void) diff --git a/0036-9pfs-add-cleanup-operation-in-FileOperations.patch b/0036-9pfs-add-cleanup-operation-in-FileOperations.patch new file mode 100644 index 0000000..d6fb0d9 --- /dev/null +++ b/0036-9pfs-add-cleanup-operation-in-FileOperations.patch @@ -0,0 +1,53 @@ +From: Li Qiang +Date: Wed, 23 Nov 2016 13:53:34 +0100 +Subject: [PATCH] 9pfs: add cleanup operation in FileOperations + +Currently, the backend of VirtFS doesn't have a cleanup +function. This will lead resource leak issues if the backed +driver allocates resources. This patch addresses this issue. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit 702dbcc274e2ca43be20ba64c758c0ca57dab91d) +--- + fsdev/file-op-9p.h | 1 + + hw/9pfs/9p.c | 6 ++++++ + 2 files changed, 7 insertions(+) + +diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h +index 6db9fea..a56dc84 100644 +--- a/fsdev/file-op-9p.h ++++ b/fsdev/file-op-9p.h +@@ -100,6 +100,7 @@ struct FileOperations + { + int (*parse_opts)(QemuOpts *, struct FsDriverEntry *); + int (*init)(struct FsContext *); ++ void (*cleanup)(struct FsContext *); + int (*lstat)(FsContext *, V9fsPath *, struct stat *); + ssize_t (*readlink)(FsContext *, V9fsPath *, char *, size_t); + int (*chmod)(FsContext *, V9fsPath *, FsCred *); +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 1b7dd84..641a348 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -3492,6 +3492,9 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp) + rc = 0; + out: + if (rc) { ++ if (s->ops->cleanup && s->ctx.private) { ++ s->ops->cleanup(&s->ctx); ++ } + g_free(s->tag); + g_free(s->ctx.fs_root); + v9fs_path_free(&path); +@@ -3501,6 +3504,9 @@ out: + + void v9fs_device_unrealize_common(V9fsState *s, Error **errp) + { ++ if (s->ops->cleanup) { ++ s->ops->cleanup(&s->ctx); ++ } + g_free(s->tag); + g_free(s->ctx.fs_root); + } diff --git a/0037-9pfs-add-cleanup-operation-for-handle-backend-driver.patch b/0037-9pfs-add-cleanup-operation-for-handle-backend-driver.patch new file mode 100644 index 0000000..ec8a434 --- /dev/null +++ b/0037-9pfs-add-cleanup-operation-for-handle-backend-driver.patch @@ -0,0 +1,44 @@ +From: Li Qiang +Date: Wed, 23 Nov 2016 13:53:34 +0100 +Subject: [PATCH] 9pfs: add cleanup operation for handle backend driver + +In the init operation of handle backend dirver, it allocates a +handle_data struct and opens a mount file. We should free these +resources when the 9pfs device is unrealized. This is what this +patch does. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit 971f406b77a6eb84e0ad27dcc416b663765aee30) +--- + hw/9pfs/9p-handle.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/hw/9pfs/9p-handle.c b/hw/9pfs/9p-handle.c +index 3d77594..1687661 100644 +--- a/hw/9pfs/9p-handle.c ++++ b/hw/9pfs/9p-handle.c +@@ -649,6 +649,14 @@ out: + return ret; + } + ++static void handle_cleanup(FsContext *ctx) ++{ ++ struct handle_data *data = ctx->private; ++ ++ close(data->mountfd); ++ g_free(data); ++} ++ + static int handle_parse_opts(QemuOpts *opts, struct FsDriverEntry *fse) + { + const char *sec_model = qemu_opt_get(opts, "security_model"); +@@ -671,6 +679,7 @@ static int handle_parse_opts(QemuOpts *opts, struct FsDriverEntry *fse) + FileOperations handle_ops = { + .parse_opts = handle_parse_opts, + .init = handle_init, ++ .cleanup = handle_cleanup, + .lstat = handle_lstat, + .readlink = handle_readlink, + .close = handle_close, diff --git a/0038-9pfs-add-cleanup-operation-for-proxy-backend-driver.patch b/0038-9pfs-add-cleanup-operation-for-proxy-backend-driver.patch new file mode 100644 index 0000000..15c5e23 --- /dev/null +++ b/0038-9pfs-add-cleanup-operation-for-proxy-backend-driver.patch @@ -0,0 +1,44 @@ +From: Li Qiang +Date: Wed, 23 Nov 2016 13:53:34 +0100 +Subject: [PATCH] 9pfs: add cleanup operation for proxy backend driver + +In the init operation of proxy backend dirver, it allocates a +V9fsProxy struct and some other resources. We should free these +resources when the 9pfs device is unrealized. This is what this +patch does. + +Signed-off-by: Li Qiang +Reviewed-by: Greg Kurz +Signed-off-by: Greg Kurz +(cherry picked from commit 898ae90a44551d25b8e956fd87372d303c82fe68) +--- + hw/9pfs/9p-proxy.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c +index f265501..336e9fe 100644 +--- a/hw/9pfs/9p-proxy.c ++++ b/hw/9pfs/9p-proxy.c +@@ -1179,9 +1179,22 @@ static int proxy_init(FsContext *ctx) + return 0; + } + ++static void proxy_cleanup(FsContext *ctx) ++{ ++ V9fsProxy *proxy = ctx->private; ++ ++ g_free(proxy->out_iovec.iov_base); ++ g_free(proxy->in_iovec.iov_base); ++ if (ctx->export_flags & V9FS_PROXY_SOCK_NAME) { ++ close(proxy->sockfd); ++ } ++ g_free(proxy); ++} ++ + FileOperations proxy_ops = { + .parse_opts = proxy_parse_opts, + .init = proxy_init, ++ .cleanup = proxy_cleanup, + .lstat = proxy_lstat, + .readlink = proxy_readlink, + .close = proxy_close, diff --git a/0039-9pfs-fix-crash-when-fsdev-is-missing.patch b/0039-9pfs-fix-crash-when-fsdev-is-missing.patch new file mode 100644 index 0000000..435d3a2 --- /dev/null +++ b/0039-9pfs-fix-crash-when-fsdev-is-missing.patch @@ -0,0 +1,29 @@ +From: Greg Kurz +Date: Tue, 3 Jan 2017 17:28:44 +0100 +Subject: [PATCH] 9pfs: fix crash when fsdev is missing + +If the user passes -device virtio-9p without the corresponding -fsdev, QEMU +dereferences a NULL pointer and crashes. + +This is a 2.8 regression introduced by commit 702dbcc274e2c. + +Signed-off-by: Greg Kurz +Reviewed-by: Li Qiang +(cherry picked from commit f2b58c43758efc61e2a49b899f5e58848489d0dc) +--- + hw/9pfs/9p.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c +index 641a348..9a89f75 100644 +--- a/hw/9pfs/9p.c ++++ b/hw/9pfs/9p.c +@@ -3492,7 +3492,7 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp) + rc = 0; + out: + if (rc) { +- if (s->ops->cleanup && s->ctx.private) { ++ if (s->ops && s->ops->cleanup && s->ctx.private) { + s->ops->cleanup(&s->ctx); + } + g_free(s->tag); diff --git a/0040-display-virtio-gpu-3d-check-virgl-capabilities-max_s.patch b/0040-display-virtio-gpu-3d-check-virgl-capabilities-max_s.patch new file mode 100644 index 0000000..1ec3b9d --- /dev/null +++ b/0040-display-virtio-gpu-3d-check-virgl-capabilities-max_s.patch @@ -0,0 +1,37 @@ +From: Prasad J Pandit +Date: Wed, 14 Dec 2016 12:31:56 +0530 +Subject: [PATCH] display: virtio-gpu-3d: check virgl capabilities max_size + +Virtio GPU device while processing 'VIRTIO_GPU_CMD_GET_CAPSET' +command, retrieves the maximum capabilities size to fill in the +response object. It continues to fill in capabilities even if +retrieved 'max_size' is zero(0), thus resulting in OOB access. +Add check to avoid it. + +Reported-by: Zhenhao Hong +Signed-off-by: Prasad J Pandit +Message-id: 20161214070156.23368-1-ppandit@redhat.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit abd7f08b2353f43274b785db8c7224f082ef4d31) +--- + hw/display/virtio-gpu-3d.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c +index 23f39de..e29f099 100644 +--- a/hw/display/virtio-gpu-3d.c ++++ b/hw/display/virtio-gpu-3d.c +@@ -371,8 +371,12 @@ static void virgl_cmd_get_capset(VirtIOGPU *g, + + virgl_renderer_get_cap_set(gc.capset_id, &max_ver, + &max_size); +- resp = g_malloc(sizeof(*resp) + max_size); ++ if (!max_size) { ++ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER; ++ return; ++ } + ++ resp = g_malloc(sizeof(*resp) + max_size); + resp->hdr.type = VIRTIO_GPU_RESP_OK_CAPSET; + virgl_renderer_fill_caps(gc.capset_id, + gc.capset_version, diff --git a/0041-virtio-gpu-fix-information-leak-in-capset-get-dispat.patch b/0041-virtio-gpu-fix-information-leak-in-capset-get-dispat.patch new file mode 100644 index 0000000..af097fc --- /dev/null +++ b/0041-virtio-gpu-fix-information-leak-in-capset-get-dispat.patch @@ -0,0 +1,37 @@ +From: Li Qiang +Date: Tue, 1 Nov 2016 05:37:57 -0700 +Subject: [PATCH] virtio-gpu: fix information leak in capset get dispatch +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In virgl_cmd_get_capset function, it uses g_malloc to allocate +a response struct to the guest. As the 'resp'struct hasn't been full +initialized it will lead the 'resp->padding' field to the guest. +Use g_malloc0 to avoid this. + +Signed-off-by: Li Qiang +Reviewed-by: Marc-André Lureau +Message-id: 58188cae.4a6ec20a.3d2d1.aff2@mx.google.com + +[ kraxel: resolved conflict ] + +Signed-off-by: Gerd Hoffmann +(cherry picked from commit 85d9d044471f93c48c5c396f7e217b4ef12f69f8) +--- + hw/display/virtio-gpu-3d.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c +index e29f099..cdd03a4 100644 +--- a/hw/display/virtio-gpu-3d.c ++++ b/hw/display/virtio-gpu-3d.c +@@ -376,7 +376,7 @@ static void virgl_cmd_get_capset(VirtIOGPU *g, + return; + } + +- resp = g_malloc(sizeof(*resp) + max_size); ++ resp = g_malloc0(sizeof(*resp) + max_size); + resp->hdr.type = VIRTIO_GPU_RESP_OK_CAPSET; + virgl_renderer_fill_caps(gc.capset_id, + gc.capset_version, diff --git a/0042-virtio-gpu-call-cleanup-mapping-function-in-resource.patch b/0042-virtio-gpu-call-cleanup-mapping-function-in-resource.patch new file mode 100644 index 0000000..37ab67b --- /dev/null +++ b/0042-virtio-gpu-call-cleanup-mapping-function-in-resource.patch @@ -0,0 +1,41 @@ +From: Li Qiang +Date: Mon, 28 Nov 2016 21:29:25 -0500 +Subject: [PATCH] virtio-gpu: call cleanup mapping function in resource destroy +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +If the guest destroy the resource before detach banking, the 'iov' +and 'addrs' field in resource is not freed thus leading memory +leak issue. This patch avoid this. + +Signed-off-by: Li Qiang +Reviewed-by: Marc-André Lureau +Message-id: 1480386565-10077-1-git-send-email-liq3ea@gmail.com +Signed-off-by: Gerd Hoffmann +(cherry picked from commit b8e23926c568f2e963af39028b71c472e3023793) +--- + hw/display/virtio-gpu.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c +index 41f8096..8903dee 100644 +--- a/hw/display/virtio-gpu.c ++++ b/hw/display/virtio-gpu.c +@@ -28,6 +28,8 @@ + static struct virtio_gpu_simple_resource* + virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id); + ++static void virtio_gpu_cleanup_mapping(struct virtio_gpu_simple_resource *res); ++ + #ifdef CONFIG_VIRGL + #include + #define VIRGL(_g, _virgl, _simple, ...) \ +@@ -359,6 +361,7 @@ static void virtio_gpu_resource_destroy(VirtIOGPU *g, + struct virtio_gpu_simple_resource *res) + { + pixman_image_unref(res->image); ++ virtio_gpu_cleanup_mapping(res); + QTAILQ_REMOVE(&g->reslist, res, next); + g_free(res); + } diff --git a/qemu.spec b/qemu.spec index 8b21342..d56daa0 100644 --- a/qemu.spec +++ b/qemu.spec @@ -68,7 +68,7 @@ Summary: QEMU is a FAST! processor emulator Name: qemu Version: 2.7.1 -Release: 1%{?rcrel}%{?dist} +Release: 2%{?rcrel}%{?dist} Epoch: 2 License: GPLv2+ and LGPLv2+ and BSD Group: Development/Tools @@ -124,6 +124,78 @@ Patch0009: 0009-qxl-Only-emit-QXL_INTERRUPT_CLIENT_MONITORS_CONFIG-o.patch # Fix keyboard issues with -ui gtk + host wayland (bz #1401211) # Posted but not yet applied upstream Patch0010: 0010-ui-use-evdev-keymap-when-running-under-wayland.patch +# CVE-2016-6836: vmxnet: Information leakage in vmxnet3_complete_packet (bz +# #1366370) +Patch0011: 0011-net-vmxnet-initialise-local-tx-descriptor.patch +# CVE-2016-7909: pcnet: Infinite loop in pcnet_rdra_addr (bz #1381196) +Patch0012: 0012-net-pcnet-check-rx-tx-descriptor-ring-length.patch +# CVE-2016-7994: virtio-gpu: memory leak in resource_create_2d (bz #1382667) +Patch0013: 0013-virtio-gpu-fix-memory-leak-in-virtio_gpu_resource_cr.patch +# CVE-2016-8577: 9pfs: host memory leakage in v9fs_read (bz #1383286) +Patch0014: 0014-9pfs-fix-potential-host-memory-leak-in-v9fs_read.patch +# CVE-2016-8578: 9pfs: potential NULL dereferencein 9pfs routines (bz +# #1383292) +Patch0015: 0015-9pfs-allocate-space-for-guest-originated-empty-strin.patch +# CVE-2016-8668: OOB buffer access in rocker switch emulation (bz #1384898) +Patch0016: 0016-net-rocker-set-limit-to-DMA-buffer-size.patch +# CVE-2016-8669: divide by zero error in serial_update_parameters (bz +# #1384911) +Patch0017: 0017-char-serial-check-divider-value-against-baud-base.patch +# CVE-2016-8909: intel-hda: infinite loop in dma buffer stream (bz #1388053) +Patch0018: 0018-audio-intel-hda-check-stream-entry-count-during-tran.patch +# Infinite loop vulnerability in a9_gtimer_update (bz #1388300) +Patch0019: 0019-timer-a9gtimer-remove-loop-to-auto-increment-compara.patch +# CVE-2016-9101: eepro100: memory leakage at device unplug (bz #1389539) +Patch0020: 0020-net-eepro100-fix-memory-leak-in-device-uninit.patch +# CVE-2016-9103: 9pfs: information leakage via xattr (bz #1389643) +Patch0021: 0021-9pfs-fix-information-leak-in-xattr-read.patch +# CVE-2016-9102: 9pfs: memory leakage when creating extended attribute (bz +# #1389551) +Patch0022: 0022-9pfs-fix-memory-leak-in-v9fs_xattrcreate.patch +# CVE-2016-9104: 9pfs: integer overflow leading to OOB access (bz #1389687) +Patch0023: 0023-9pfs-add-xattrwalk_fid-field-in-V9fsXattr-struct.patch +Patch0024: 0024-9pfs-convert-len-copied_len-field-in-V9fsXattr-to-th.patch +Patch0025: 0025-9pfs-fix-integer-overflow-issue-in-xattr-read-write.patch +# CVE-2016-9105: 9pfs: memory leakage in v9fs_link (bz #1389704) +Patch0026: 0026-9pfs-fix-memory-leak-in-v9fs_link.patch +# CVE-2016-9106: 9pfs: memory leakage in v9fs_write (bz #1389713) +Patch0027: 0027-9pfs-fix-memory-leak-in-v9fs_write.patch +# CVE-2016-9381: xen: incautious about shared ring processing (bz #1397385) +Patch0028: 0028-xen-fix-ioreq-handling.patch +# CVE-2016-9921: Divide by zero vulnerability in cirrus_do_copy (bz +# #1399054) +Patch0029: 0029-display-cirrus-check-vga-bits-per-pixel-bpp-value.patch +# CVE-2016-9776: infinite loop while receiving data in mcf_fec_receive (bz +# #1400830) +Patch0030: 0030-net-mcf-check-receive-buffer-size-register-value.patch +# CVE-2016-9845: information leakage in virgl_cmd_get_capset_info (bz +# #1402247) +Patch0031: 0031-virtio-gpu-fix-information-leak-in-getting-capset-in.patch +# CVE-2016-9846: virtio-gpu: memory leakage while updating cursor data (bz +# #1402258) +Patch0032: 0032-virtio-gpu-fix-memory-leak-in-update_cursor_data_vir.patch +# CVE-2016-9907: usbredir: memory leakage when destroying redirector (bz +# #1402266) +Patch0033: 0033-usbredir-free-vm_change_state_handler-in-usbredir-de.patch +# CVE-2016-9911: usb: ehci: memory leakage in ehci_init_transfer (bz +# #1402273) +Patch0034: 0034-usb-ehci-fix-memory-leak-in-ehci_init_transfer.patch +# CVE-2016-9913: 9pfs: memory leakage via proxy/handle callbacks (bz +# #1402277) +Patch0035: 0035-9pfs-adjust-the-order-of-resource-cleanup-in-device-.patch +Patch0036: 0036-9pfs-add-cleanup-operation-in-FileOperations.patch +Patch0037: 0037-9pfs-add-cleanup-operation-for-handle-backend-driver.patch +Patch0038: 0038-9pfs-add-cleanup-operation-for-proxy-backend-driver.patch +Patch0039: 0039-9pfs-fix-crash-when-fsdev-is-missing.patch +# CVE-2016-10028: virtio-gpu-3d: OOB access while reading virgl capabilities +# (bz #1406368) +Patch0040: 0040-display-virtio-gpu-3d-check-virgl-capabilities-max_s.patch +# CVE-2016-9908: virtio-gpu: information leakage in virgl_cmd_get_capset (bz +# #1402263) +Patch0041: 0041-virtio-gpu-fix-information-leak-in-capset-get-dispat.patch +# CVE-2016-9912: virtio-gpu: memory leakage when destroying gpu resource (bz +# #1402285) +Patch0042: 0042-virtio-gpu-call-cleanup-mapping-function-in-resource.patch # documentation deps BuildRequires: texi2html @@ -1595,6 +1667,48 @@ getent passwd qemu >/dev/null || \ %changelog +* Mon Jan 16 2017 Cole Robinson - 2:2.7.1-2 +- CVE-2016-6836: vmxnet: Information leakage in vmxnet3_complete_packet (bz + #1366370) +- CVE-2016-7909: pcnet: Infinite loop in pcnet_rdra_addr (bz #1381196) +- CVE-2016-7994: virtio-gpu: memory leak in resource_create_2d (bz #1382667) +- CVE-2016-8577: 9pfs: host memory leakage in v9fs_read (bz #1383286) +- CVE-2016-8578: 9pfs: potential NULL dereferencein 9pfs routines (bz + #1383292) +- CVE-2016-8668: OOB buffer access in rocker switch emulation (bz #1384898) +- CVE-2016-8669: divide by zero error in serial_update_parameters (bz + #1384911) +- CVE-2016-8909: intel-hda: infinite loop in dma buffer stream (bz #1388053) +- Infinite loop vulnerability in a9_gtimer_update (bz #1388300) +- CVE-2016-9101: eepro100: memory leakage at device unplug (bz #1389539) +- CVE-2016-9103: 9pfs: information leakage via xattr (bz #1389643) +- CVE-2016-9102: 9pfs: memory leakage when creating extended attribute (bz + #1389551) +- CVE-2016-9104: 9pfs: integer overflow leading to OOB access (bz #1389687) +- CVE-2016-9105: 9pfs: memory leakage in v9fs_link (bz #1389704) +- CVE-2016-9106: 9pfs: memory leakage in v9fs_write (bz #1389713) +- CVE-2016-9381: xen: incautious about shared ring processing (bz #1397385) +- CVE-2016-9921: Divide by zero vulnerability in cirrus_do_copy (bz + #1399054) +- CVE-2016-9776: infinite loop while receiving data in mcf_fec_receive (bz + #1400830) +- CVE-2016-9845: information leakage in virgl_cmd_get_capset_info (bz + #1402247) +- CVE-2016-9846: virtio-gpu: memory leakage while updating cursor data (bz + #1402258) +- CVE-2016-9907: usbredir: memory leakage when destroying redirector (bz + #1402266) +- CVE-2016-9911: usb: ehci: memory leakage in ehci_init_transfer (bz + #1402273) +- CVE-2016-9913: 9pfs: memory leakage via proxy/handle callbacks (bz + #1402277) +- CVE-2016-10028: virtio-gpu-3d: OOB access while reading virgl capabilities + (bz #1406368) +- CVE-2016-9908: virtio-gpu: information leakage in virgl_cmd_get_capset (bz + #1402263) +- CVE-2016-9912: virtio-gpu: memory leakage when destroying gpu resource (bz + #1402285) + * Mon Jan 09 2017 Cole Robinson - 2:2.7.1-1 - Update to qemu 2.7.1