rpms/qemu
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

CVE-2016-6836: vmxnet: Information leakage in vmxnet3_complete_packet (bz #1366370)

Browse Source 
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-8910: rtl8139: infinite loop while transmit in C+ mode (bz #1388047)
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)
This commit is contained in:
Cole Robinson 2017-01-16 15:58:15 -05:00
parent 5a6b758586
commit 4d7edd7e33
34 changed files with 1487 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
0014-net-vmxnet-initialise-local-tx-descriptor.patch Normal file
View File

@ -0,0 +1,30 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(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 a6ce16e..360290d 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -529,6 +529,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);

34
0015-net-pcnet-check-rx-tx-descriptor-ring-length.patch Normal file
View File

@ -0,0 +1,34 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <liqiang6-s@360.cn>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(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;

32
0016-virtio-gpu-fix-memory-leak-in-virtio_gpu_resource_cr.patch Normal file
View File

@ -0,0 +1,32 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 57df486e.8379240a.c3620.ff81@mx.google.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 c181fb3..d345276 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -323,6 +323,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;
}

36
0017-9pfs-fix-potential-host-memory-leak-in-v9fs_read.patch Normal file
View File

@ -0,0 +1,36 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 d47f5de..afb1c4e 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1807,14 +1807,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) {

56
0018-9pfs-allocate-space-for-guest-originated-empty-strin.patch Normal file
View File

@ -0,0 +1,56 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
[groug, rewritten title and changelog,
fix empty string check in v9fs_xattrwalk()]
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 fb40bdf..741e4d9 100644
--- a/fsdev/9p-iov-marshal.c
+++ b/fsdev/9p-iov-marshal.c
@@ -127,7 +127,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 afb1c4e..856544d 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3151,7 +3151,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
*/

33
0019-net-rocker-set-limit-to-DMA-buffer-size.patch Normal file
View File

@ -0,0 +1,33 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(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;

34
0020-char-serial-check-divider-value-against-baud-base.patch Normal file
View File

@ -0,0 +1,34 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-Id: <1476251888-20238-1-git-send-email-ppandit@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(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 6d815b5..3998131 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -152,8 +152,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;

31
0021-net-rtl8139-limit-processing-of-ring-descriptors.patch Normal file
View File

@ -0,0 +1,31 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
Date: Fri, 21 Oct 2016 17:39:29 +0530
Subject: [PATCH] net: rtl8139: limit processing of ring descriptors
RTL8139 ethernet controller in C+ mode supports multiple
descriptor rings, each with maximum of 64 descriptors. While
processing transmit descriptor ring in 'rtl8139_cplus_transmit',
it does not limit the descriptor count and runs forever. Add
check to avoid it.
Reported-by: Andrew Henderson <hendersa@icculus.org>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit c7c35916692fe010fef25ac338443d3fe40be225)
---
hw/net/rtl8139.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index 1e5ec14..138fa62 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -2379,7 +2379,7 @@ static void rtl8139_cplus_transmit(RTL8139State *s)
{
int txcount = 0;
- while (rtl8139_cplus_transmit_one(s))
+ while (txcount < 64 && rtl8139_cplus_transmit_one(s))
{
++txcount;
}

35
0022-audio-intel-hda-check-stream-entry-count-during-tran.patch Normal file
View File

@ -0,0 +1,35 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1476949224-6865-1-git-send-email-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 d372d4a..cd3b03c 100644
--- a/hw/audio/intel-hda.c
+++ b/hw/audio/intel-hda.c
@@ -415,7 +415,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;

48
0023-timer-a9gtimer-remove-loop-to-auto-increment-compara.patch Normal file
View File

@ -0,0 +1,48 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <liqiang6-s@360.cn>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 1476733226-11635-1-git-send-email-ppandit@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(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;

27
0024-net-eepro100-fix-memory-leak-in-device-uninit.patch Normal file
View File

@ -0,0 +1,27 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(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 9b4b9b5..c39fd19 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);
}

29
0025-9pfs-fix-information-leak-in-xattr-read.patch Normal file
View File

@ -0,0 +1,29 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 856544d..0735246 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3259,7 +3259,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:

32
0026-9pfs-fix-memory-leak-in-v9fs_xattrcreate.patch Normal file
View File

@ -0,0 +1,32 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
[groug, updated the changelog to indicate how the leak can occur]
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 0735246..54e5ed4 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3259,6 +3259,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);

70
0027-9pfs-add-xattrwalk_fid-field-in-V9fsXattr-struct.patch Normal file
View File

@ -0,0 +1,70 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <groug@kaod.org>
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 54e5ed4..22690f2 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -308,7 +308,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;
}
@@ -3166,7 +3166,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,
@@ -3199,7 +3199,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,
@@ -3255,6 +3255,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 589b3a5..5750d67 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -167,6 +167,7 @@ typedef struct V9fsXattr
void *value;
V9fsString name;
int flags;
+ bool xattrwalk_fid;
} V9fsXattr;
/*

44
0028-9pfs-convert-len-copied_len-field-in-V9fsXattr-to-th.patch Normal file
View File

@ -0,0 +1,44 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <groug@kaod.org>
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 5750d67..4e3bc52 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -162,8 +162,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;

89
0029-9pfs-fix-integer-overflow-issue-in-xattr-read-write.patch Normal file
View File

@ -0,0 +1,89 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <groug@kaod.org>
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-By: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 22690f2..5126459 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1627,20 +1627,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) {
@@ -1959,23 +1956,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;

30
0030-9pfs-fix-memory-leak-in-v9fs_link.patch Normal file
View File

@ -0,0 +1,30 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
[groug, rephrased the changelog]
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 5126459..0de545b 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -2385,6 +2385,7 @@ static void v9fs_link(void *opaque)
if (!err) {
err = offset;
}
+ put_fid(pdu, oldfidp);
out:
put_fid(pdu, dfidp);
out_nofid:

31
0031-9pfs-fix-memory-leak-in-v9fs_write.patch Normal file
View File

@ -0,0 +1,31 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Greg Kurz <groug@kaod.org>
[groug, rephrased the changelog]
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 0de545b..86f44db 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -2062,7 +2062,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);

71
0032-xen-fix-ioreq-handling.patch Normal file
View File

@ -0,0 +1,71 @@
From: Jan Beulich <JBeulich@suse.com>
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 <yanghongke@huawei.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
(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 039680a..ba823c3 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -797,6 +797,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);
@@ -833,6 +837,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++) {
@@ -997,11 +1005,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);
@@ -1032,7 +1042,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, &copy);
+ req->data = copy.data;
if (req->state != STATE_IOREQ_INPROCESS) {
fprintf(stderr, "Badness in I/O request ... not in service?!: "

73
0033-display-cirrus-check-vga-bits-per-pixel-bpp-value.patch Normal file
View File

@ -0,0 +1,73 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 1476776717-24807-1-git-send-email-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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;
}
/***************************************

31
0034-net-mcf-check-receive-buffer-size-register-value.patch Normal file
View File

@ -0,0 +1,31 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <wjjzhang@tencent.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(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 6d3418e..8a69fa2 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);

34
0035-virtio-gpu-fix-information-leak-in-getting-capset-in.patch Normal file
View File

@ -0,0 +1,34 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Message-id: 5818661e.0860240a.77264.7a56@mx.google.com
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 fa19294..5878809 100644
--- a/hw/display/virtio-gpu-3d.c
+++ b/hw/display/virtio-gpu-3d.c
@@ -345,6 +345,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,

33
0036-virtio-gpu-fix-memory-leak-in-update_cursor_data_vir.patch Normal file
View File

@ -0,0 +1,33 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Message-id: 58187760.41d71c0a.cca75.4cb9@mx.google.com
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 d345276..f41afc7 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -79,6 +79,7 @@ static void update_cursor_data_virgl(VirtIOGPU *g,
if (width != s->current_cursor->width ||
height != s->current_cursor->height) {
+ free(data);
return;
}

51
0037-usbredir-free-vm_change_state_handler-in-usbredir-de.patch Normal file
View File

@ -0,0 +1,51 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 58216976.d0236b0a.77b99.bcd6@mx.google.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 8d80540..136cacc 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -131,6 +131,7 @@ struct USBRedirDevice {
struct usbredirfilter_rule *filter_rules;
int filter_rules_count;
int compatible_speedmask;
+ VMChangeStateEntry *vmstate;
};
#define TYPE_USB_REDIR "usb-redir"
@@ -1406,7 +1407,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)
@@ -1443,6 +1445,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)

28
0038-usb-ehci-fix-memory-leak-in-ehci_init_transfer.patch Normal file
View File

@ -0,0 +1,28 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Message-id: 5821c0f4.091c6b0a.e0c92.e811@mx.google.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 92241bb..b8559e2 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;
}

40
0039-9pfs-adjust-the-order-of-resource-cleanup-in-device-.patch Normal file
View File

@ -0,0 +1,40 @@
From: Li Qiang <liq3ea@gmail.com>
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 <liq3ea@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 86f44db..6979c58 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3481,8 +3481,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;
@@ -3490,8 +3490,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)

53
0040-9pfs-add-cleanup-operation-in-FileOperations.patch Normal file
View File

@ -0,0 +1,53 @@
From: Li Qiang <liq3ea@gmail.com>
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 <liq3ea@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 b8c2602..0681021 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -99,6 +99,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 6979c58..84be1c8 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3481,6 +3481,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);
@@ -3490,6 +3493,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);
}

44
0041-9pfs-add-cleanup-operation-for-handle-backend-driver.patch Normal file
View File

@ -0,0 +1,44 @@
From: Li Qiang <liq3ea@gmail.com>
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 <liq3ea@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 8940414..6ce923d 100644
--- a/hw/9pfs/9p-handle.c
+++ b/hw/9pfs/9p-handle.c
@@ -651,6 +651,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");
@@ -673,6 +681,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,

44
0042-9pfs-add-cleanup-operation-for-proxy-backend-driver.patch Normal file
View File

@ -0,0 +1,44 @@
From: Li Qiang <liq3ea@gmail.com>
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 <liq3ea@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(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 00a4eb2..7c6aaf3 100644
--- a/hw/9pfs/9p-proxy.c
+++ b/hw/9pfs/9p-proxy.c
@@ -1181,9 +1181,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,

29
0043-9pfs-fix-crash-when-fsdev-is-missing.patch Normal file
View File

@ -0,0 +1,29 @@
From: Greg Kurz <groug@kaod.org>
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 <groug@kaod.org>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
(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 84be1c8..be2095a 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3481,7 +3481,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);

37
0044-display-virtio-gpu-3d-check-virgl-capabilities-max_s.patch Normal file
View File

@ -0,0 +1,37 @@
From: Prasad J Pandit <pjp@fedoraproject.org>
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 <zhenhaohong@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 20161214070156.23368-1-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 5878809..bb2e9a1 100644
--- a/hw/display/virtio-gpu-3d.c
+++ b/hw/display/virtio-gpu-3d.c
@@ -369,8 +369,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,

37
0045-virtio-gpu-fix-information-leak-in-capset-get-dispat.patch Normal file
View File

@ -0,0 +1,37 @@
From: Li Qiang <liqiang6-s@360.cn>
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 <liqiang6-s@360.cn>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 58188cae.4a6ec20a.3d2d1.aff2@mx.google.com
[ kraxel: resolved conflict ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 bb2e9a1..420187e 100644
--- a/hw/display/virtio-gpu-3d.c
+++ b/hw/display/virtio-gpu-3d.c
@@ -374,7 +374,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,

41
0046-virtio-gpu-call-cleanup-mapping-function-in-resource.patch Normal file
View File

@ -0,0 +1,41 @@
From: Li Qiang <liq3ea@gmail.com>
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 <liq3ea@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 1480386565-10077-1-git-send-email-liq3ea@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(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 f41afc7..4ccc8bc 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -23,6 +23,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 "virglrenderer.h"
#define VIRGL(_g, _virgl, _simple, ...) \
@@ -349,6 +351,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);
}

121
qemu.spec
View File

@ -65,7 +65,7 @@
Summary: QEMU is a FAST! processor emulator
Name: qemu
Version: 2.6.2
Release: 5%{?rcrel}%{?dist}
Release: 6%{?rcrel}%{?dist}
Epoch: 2
License: GPLv2+ and LGPLv2+ and BSD
Group: Development/Tools
@ -126,6 +126,81 @@ Patch0011: 0011-xhci-limit-the-number-of-link-trbs-we-are-willing-to.patch
Patch0012: 0012-usb-ehci-fix-memory-leak-in-ehci_process_itd.patch
# Fix flickering display with boxes + wayland VM (bz #1266484)
Patch0013: 0013-qxl-Only-emit-QXL_INTERRUPT_CLIENT_MONITORS_CONFIG-o.patch
# CVE-2016-6836: vmxnet: Information leakage in vmxnet3_complete_packet (bz
# #1366370)
Patch0014: 0014-net-vmxnet-initialise-local-tx-descriptor.patch
# CVE-2016-7909: pcnet: Infinite loop in pcnet_rdra_addr (bz #1381196)
Patch0015: 0015-net-pcnet-check-rx-tx-descriptor-ring-length.patch
# CVE-2016-7994: virtio-gpu: memory leak in resource_create_2d (bz #1382667)
Patch0016: 0016-virtio-gpu-fix-memory-leak-in-virtio_gpu_resource_cr.patch
# CVE-2016-8577: 9pfs: host memory leakage in v9fs_read (bz #1383286)
Patch0017: 0017-9pfs-fix-potential-host-memory-leak-in-v9fs_read.patch
# CVE-2016-8578: 9pfs: potential NULL dereferencein 9pfs routines (bz
# #1383292)
Patch0018: 0018-9pfs-allocate-space-for-guest-originated-empty-strin.patch
# CVE-2016-8668: OOB buffer access in rocker switch emulation (bz #1384898)
Patch0019: 0019-net-rocker-set-limit-to-DMA-buffer-size.patch
# CVE-2016-8669: divide by zero error in serial_update_parameters (bz
# #1384911)
Patch0020: 0020-char-serial-check-divider-value-against-baud-base.patch
# CVE-2016-8910: rtl8139: infinite loop while transmit in C+ mode (bz
# #1388047)
Patch0021: 0021-net-rtl8139-limit-processing-of-ring-descriptors.patch
# CVE-2016-8909: intel-hda: infinite loop in dma buffer stream (bz #1388053)
Patch0022: 0022-audio-intel-hda-check-stream-entry-count-during-tran.patch
# Infinite loop vulnerability in a9_gtimer_update (bz #1388300)
Patch0023: 0023-timer-a9gtimer-remove-loop-to-auto-increment-compara.patch
# CVE-2016-9101: eepro100: memory leakage at device unplug (bz #1389539)
Patch0024: 0024-net-eepro100-fix-memory-leak-in-device-uninit.patch
# CVE-2016-9103: 9pfs: information leakage via xattr (bz #1389643)
Patch0025: 0025-9pfs-fix-information-leak-in-xattr-read.patch
# CVE-2016-9102: 9pfs: memory leakage when creating extended attribute (bz
# #1389551)
Patch0026: 0026-9pfs-fix-memory-leak-in-v9fs_xattrcreate.patch
# CVE-2016-9104: 9pfs: integer overflow leading to OOB access (bz #1389687)
Patch0027: 0027-9pfs-add-xattrwalk_fid-field-in-V9fsXattr-struct.patch
Patch0028: 0028-9pfs-convert-len-copied_len-field-in-V9fsXattr-to-th.patch
Patch0029: 0029-9pfs-fix-integer-overflow-issue-in-xattr-read-write.patch
# CVE-2016-9105: 9pfs: memory leakage in v9fs_link (bz #1389704)
Patch0030: 0030-9pfs-fix-memory-leak-in-v9fs_link.patch
# CVE-2016-9106: 9pfs: memory leakage in v9fs_write (bz #1389713)
Patch0031: 0031-9pfs-fix-memory-leak-in-v9fs_write.patch
# CVE-2016-9381: xen: incautious about shared ring processing (bz #1397385)
Patch0032: 0032-xen-fix-ioreq-handling.patch
# CVE-2016-9921: Divide by zero vulnerability in cirrus_do_copy (bz
# #1399054)
Patch0033: 0033-display-cirrus-check-vga-bits-per-pixel-bpp-value.patch
# CVE-2016-9776: infinite loop while receiving data in mcf_fec_receive (bz
# #1400830)
Patch0034: 0034-net-mcf-check-receive-buffer-size-register-value.patch
# CVE-2016-9845: information leakage in virgl_cmd_get_capset_info (bz
# #1402247)
Patch0035: 0035-virtio-gpu-fix-information-leak-in-getting-capset-in.patch
# CVE-2016-9846: virtio-gpu: memory leakage while updating cursor data (bz
# #1402258)
Patch0036: 0036-virtio-gpu-fix-memory-leak-in-update_cursor_data_vir.patch
# CVE-2016-9907: usbredir: memory leakage when destroying redirector (bz
# #1402266)
Patch0037: 0037-usbredir-free-vm_change_state_handler-in-usbredir-de.patch
# CVE-2016-9911: usb: ehci: memory leakage in ehci_init_transfer (bz
# #1402273)
Patch0038: 0038-usb-ehci-fix-memory-leak-in-ehci_init_transfer.patch
# CVE-2016-9913: 9pfs: memory leakage via proxy/handle callbacks (bz
# #1402277)
Patch0039: 0039-9pfs-adjust-the-order-of-resource-cleanup-in-device-.patch
Patch0040: 0040-9pfs-add-cleanup-operation-in-FileOperations.patch
Patch0041: 0041-9pfs-add-cleanup-operation-for-handle-backend-driver.patch
Patch0042: 0042-9pfs-add-cleanup-operation-for-proxy-backend-driver.patch
Patch0043: 0043-9pfs-fix-crash-when-fsdev-is-missing.patch
# CVE-2016-10028: virtio-gpu-3d: OOB access while reading virgl capabilities
# (bz #1406368)
Patch0044: 0044-display-virtio-gpu-3d-check-virgl-capabilities-max_s.patch
# CVE-2016-9908: virtio-gpu: information leakage in virgl_cmd_get_capset (bz
# #1402263)
Patch0045: 0045-virtio-gpu-fix-information-leak-in-capset-get-dispat.patch
# CVE-2016-9912: virtio-gpu: memory leakage when destroying gpu resource (bz
# #1402285)
Patch0046: 0046-virtio-gpu-call-cleanup-mapping-function-in-resource.patch
# documentation deps
@ -1588,6 +1663,50 @@ getent passwd qemu >/dev/null || \
%changelog
* Mon Jan 16 2017 Cole Robinson <crobinso@redhat.com> - 2:2.6.2-6
- 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-8910: rtl8139: infinite loop while transmit in C+ mode (bz
#1388047)
- 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)
* Sun Nov 06 2016 Cole Robinson <crobinso@redhat.com> - 2:2.6.2-5
- Fix qemu-user-static binfmt on f24 (bz 1388250)