Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 24f3078a)

Conflicts:
	tests/qemu-iotests/group

*fix context mismatches in group file
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

cloop stores the number of compressed blocks in the n_blocks header
field.  The file actually contains n_blocks + 1 offsets, where the extra
offset is the end-of-file offset.

The following line in cloop_read_block() results in an out-of-bounds
offsets[] access:

    uint32_t bytes = s->offsets[block_num + 1] - s->offsets[block_num];

This patch allocates and loads the extra offset so that
cloop_read_block() works correctly when the last block is accessed.

Notice that we must free s->offsets[] unconditionally now since there is
always an end-of-file offset.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 42d43d35)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The offsets[] array allows efficient seeking and tells us the maximum
compressed data size.  If the offsets are bogus the maximum compressed
data size will be unrealistic.

This could cause g_malloc() to abort and bogus offsets mean the image is
broken anyway.  Therefore we should refuse such images.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit f56b9bc3)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Limit offsets_size to 512 MB so that:

1. g_malloc() does not abort due to an unreasonable size argument.

2. offsets_size does not overflow the bdrv_pread() int size argument.

This limit imposes a maximum image size of 16 TB at 256 KB block size.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 7b103b36)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The following integer overflow in offsets_size can lead to out-of-bounds
memory stores when n_blocks has a huge value:

    uint32_t n_blocks, offsets_size;
    [...]
    ret = bdrv_pread(bs->file, 128 + 4, &s->n_blocks, 4);
    [...]
    s->n_blocks = be32_to_cpu(s->n_blocks);

    /* read offsets */
    offsets_size = s->n_blocks * sizeof(uint64_t);
    s->offsets = g_malloc(offsets_size);

    [...]

    for(i=0;i<s->n_blocks;i++) {
        s->offsets[i] = be64_to_cpu(s->offsets[i]);

offsets_size can be smaller than n_blocks due to integer overflow.
Therefore s->offsets[] is too small when the for loop byteswaps offsets.

This patch refuses to open files if offsets_size would overflow.

Note that changing the type of offsets_size is not a fix since 32-bit
hosts still only have 32-bit size_t.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 509a41ba)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Avoid unbounded s->uncompressed_block memory allocation by checking that
the block_size header field has a reasonable value.  Also enforce the
assumption that the value is a non-zero multiple of 512.

These constraints conform to cloop 2.639's code so we accept existing
image files.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit d65f97a8)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Add a cloop format-specific test case.  Later patches add tests for
input validation to the script.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 05560fce)

Conflicts:
	tests/qemu-iotests/group

*fixed context mismatches in group file
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Add the cloop block driver to qemu-iotests.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 47f73da0)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

if a saved vm has unknown flags in the memory data qemu
currently simply ignores this flag and continues which
yields in an unpredictable result.

This patch catches all unknown flags and aborts the
loading of the vm. Additionally error reports are thrown
if the migration aborts abnormally.
Signed-off-by: NPeter Lieven <pl@kamp.de>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit db80face)

Conflicts:
	arch_init.c

*removed unecessary context from 4798fe55Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

version_id is checked twice in the ram_load.
Signed-off-by: NChenLiang <chenliang88@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 21a246a4)

*prereq for db80face backport
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

It's a loop from i < num_sg  and the array is VIRTQUEUE_MAX_SIZE - so
it's OK if the value read is VIRTQUEUE_MAX_SIZE.

Not a big problem in practice as people don't use
such big queues, but it's inelegant.
Reported-by: N"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 93725140)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

KVM only supports MSIX table size up to 256 vectors,
but some assigned devices support more vectors,
at the moment attempts to assign them fail with EINVAL.

Tweak the MSIX capability exposed to guest to limit table size
to a supported value.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NGonglei <arei.gonglei@huawei.com>
Cc: qemu-stable@nongnu.org
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 639973a4)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Current guest kernels try allocating as many vectors as the quota is.
For example, in the case of virtio-net (which has just 3 vectors)
the guest requests 4 vectors (that is the quota in the test) and
the existing ibm,change-msi handler returns 4. But before it returns,
it calls msix_set_message() in a loop and corrupts memory behind
the end of msix_table.

This limits the number of vectors returned by ibm,change-msi to
the maximum supported by the actual device.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-stable@nongnu.org
[agraf: squash in bugfix from aik]
Signed-off-by: NAlexander Graf <agraf@suse.de>
(cherry picked from commit b26696b5)

*s/error_report/fprintf/ to reflect v1.7.x error reporting style
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The ARM target-specific code in elfload.c was incorrectly allowing
the 64-bit ARM target to use most of the existing 32-bit definitions:
most noticably this meant that our HWCAP bits passed to the guest
were wrong, and register handling when dumping core was totally
broken. Fix this by properly separating the 64 and 32 bit code,
since they have more differences than similarities.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
(cherry picked from commit 24e76ff0)

Conflicts:
	linux-user/elfload.c
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The kernel has added support for a number of new ARM HWCAP bits;
add them to QEMU, including support for setting them where we have
a corresponding CPU feature bit.

We were also incorrectly setting the VFPv3D16 HWCAP -- this means
"only 16 D registers", not "supports 16-bit floating point format";
since QEMU always has 32 D registers for VFPv3, we can just remove
the line that incorrectly set this bit.

The kernel does not set the HWCAP_FPA even if it is providing FPA
emulation via nwfpe, so don't set this bit in QEMU either.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
(cherry picked from commit 24682654)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The ELF HWCAP bits for ARM features THUMBEE, NEON, VFPv3 and VFPv3D16 are
all off by one compared to the kernel definitions. Fix this discrepancy
and add in the missing CRUNCH bit which was the cause of the off-by-one
error. (We don't emulate any of the CPUs which have that weird hardware,
so it's otherwise uninteresting to us.)

Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
(cherry picked from commit 43ce393e)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Message-id: 1398926097-28097-2-git-send-email-edgar.iglesias@gmail.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
(cherry picked from commit fed3ffb9)

Conflicts:
	target-arm/helper.c
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

BND0-3, BNDCFGU, BNDCFGS, BNDSTATUS were not zeroed on reset, but they
should be (Intel Instruction Set Extensions Programming Reference
319433-015, pages 9-4 and 9-6).  Same for YMM.

XCR0 should be reset to 1.

TSC and TSC_RESET were zeroed already by the memset, remove the explicit
assignments.

Cc: Andreas Faerber <afaerber@suse.de>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 05e7e819)

Conflicts:
	target-i386/cpu.c
	target-i386/cpu.h

*removed dependency on 79e9ebebSigned-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Incoming migration with stellaris_enet is unsafe.
It's being reworked, but for now, simply block it
since noone is using it anyway.
Block outgoing migration for good measure.

CVE-2013-4532
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Malformed input can have config_len in migration stream
exceed the array size allocated on destination, the
result will be heap overflow.

To fix, that config_len matches on both sides.

CVE-2014-0182
Reported-by: N"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

--

v2: use %ix and %zx to print config_len values
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit a890a2f9)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

At the moment we require vmstate definitions to set minimum_version_id_old
to the same value as minimum_version_id if they do not provide a
load_state_old handler. Since the load_state_old functionality is
required only for a handful of devices that need to retain migration
compatibility with a pre-vmstate implementation, this means the bulk
of devices have pointless boilerplate. Relax the definition so that
minimum_version_id_old is ignored if there is no load_state_old handler.

Note that under the old scheme we would segfault if the vmstate
specified a minimum_version_id_old that was less than minimum_version_id
but did not provide a load_state_old function, and the incoming state
specified a version number between minimum_version_id_old and
minimum_version_id. Under the new scheme this will just result in
our failing the migration.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 767adce2)

Conflicts:
	vmstate.c

*removed dependency on b6fcfa59 (Move VMState code to vmstate.c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4541

s->setup_len and s->setup_index are fed into usb_packet_copy as
size/offset into s->data_buf, it's possible for invalid state to exploit
this to load arbitrary data.

setup_len and setup_index should be checked to make sure
they are not negative.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 9f8e9895)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

As the macro verifies the value is positive, rename it
to make the function clearer.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 3476436a)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4542

hw/scsi/scsi-bus.c invokes load_request.

 virtio_scsi_load_request does:
    qemu_get_buffer(f, (unsigned char *)&req->elem, sizeof(req->elem));

this probably can make elem invalid, for example,
make in_num or out_num huge, then:

    virtio_scsi_parse_req(s, vs->cmd_vqs[n], req);

will do:

    if (req->elem.out_num > 1) {
        qemu_sgl_init_external(req, &req->elem.out_sg[1],
                               &req->elem.out_addr[1],
                               req->elem.out_num - 1);
    } else {
        qemu_sgl_init_external(req, &req->elem.in_sg[1],
                               &req->elem.in_addr[1],
                               req->elem.in_num - 1);
    }

and this will access out of array bounds.

Note: this adds security checks within assert calls since
SCSIBusInfo's load_request cannot fail.
For now simply disable builds with NDEBUG - there seems
to be little value in supporting these.

Cc: Andreas Färber <afaerber@suse.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 3c3ce981)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4540

Within scoop_gpio_handler_update, if prev_level has a high bit set, then
we get bit > 16 and that causes a buffer overrun.

Since prev_level comes from wire indirectly, this can
happen on invalid state load.

Similarly for gpio_level and gpio_dir.

To fix, limit to 16 bit.
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 52f91c37)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4539

s->precision, nextprecision, function and nextfunction
come from wire and are used
as idx into resolution[] in TSC_CUT_RESOLUTION.

Validate after load to avoid buffer overrun.

Cc: Andreas Färber <afaerber@suse.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 5193be3b)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4538

s->cmd_len used as index in ssd0323_transfer() to store 32-bit field.
Possible this field might then be supplied by guest to overwrite a
return addr somewhere. Same for row/col fields, which are indicies into
framebuffer array.

To fix validate after load.

Additionally, validate that the row/col_start/end are within bounds;
otherwise the guest can provoke an overrun by either setting the _end
field so large that the row++ increments just walk off the end of the
array, or by setting the _start value to something bogus and then
letting the "we hit end of row" logic reset row to row_start.

For completeness, validate mode as well.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit ead7a57d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4537

s->arglen is taken from wire and used as idx
in ssi_sd_transfer().

Validate it before access.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit a9c380db)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4533

s->rx_level is read from the wire and used to determine how many bytes
to subsequently read into s->rx_fifo[]. If s->rx_level exceeds the
length of s->rx_fifo[] the buffer can be overrun with arbitrary data
from the wire.

Fix this by validating rx_level against the size of s->rx_fifo.

Cc: Don Koch <dkoch@verizon.com>
Reported-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NDon Koch <dkoch@verizon.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit caa881ab)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4535
CVE-2013-4536

Both virtio-block and virtio-serial read,
VirtQueueElements are read in as buffers, and passed to
virtqueue_map_sg(), where num_sg is taken from the wire and can force
writes to indicies beyond VIRTQUEUE_MAX_SIZE.

To fix, validate num_sg.
Reported-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 36cf2a37)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4534

opp->nb_cpus is read from the wire and used to determine how many
IRQDest elements to read into opp->dst[]. If the value exceeds the
length of opp->dst[], MAX_CPU, opp->dst[] can be overrun with arbitrary
data from the wire.

Fix this by failing migration if the value read from the wire exceeds
MAX_CPU.
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 73d963c0)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-6399

vdev->queue_sel is read from the wire, and later used in the
emulation code as an index into vdev->vq[]. If the value of
vdev->queue_sel exceeds the length of vdev->vq[], currently
allocated to be VIRTIO_PCI_QUEUE_MAX elements, subsequent PIO
operations such as VIRTIO_PCI_QUEUE_PFN can be used to overrun
the buffer with arbitrary data originating from the source.

Fix this by failing migration if the value from the wire exceeds
VIRTIO_PCI_QUEUE_MAX.
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 4b53c2c7)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4531

cpreg_vmstate_indexes is a VARRAY_INT32. A negative value for
cpreg_vmstate_array_len will cause a buffer overflow.

VMSTATE_INT32_LE was supposed to protect against this
but doesn't because it doesn't validate that input is
non-negative.

Fix this macro to valide the value appropriately.

The only other user of VMSTATE_INT32_LE doesn't
ever use negative numbers so it doesn't care.
Reported-by: NAnthony Liguori <anthony@codemonkey.ws>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit d2ef4b61)

Conflicts:
	vmstate.c

*removed dependency on b6fcfa59 (Move VMState code to vmstate.c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Fix comparison of vmstate_info_int32_le so that it succeeds if loaded
value is (l)ess than or (e)qual

When the comparison succeeds, assign the value loaded
  This is a change in behaviour but I think the original intent, since
  the idea is to check if the version/size of the thing you're loading is
  less than some limit, but you might well want to do something based on
  the actual version/size in the file

Fix up comment and name text
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 24a370ef)

Conflicts:
	vmstate.c

*removed dependency on b6fcfa59 (Move VMState code to vmstate.c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4530

pl022.c did not bounds check tx_fifo_head and
rx_fifo_head after loading them from file and
before they are used to dereference array.

Reported-by: Michael S. Tsirkin <mst@redhat.com
Reported-by: NAnthony Liguori <anthony@codemonkey.ws>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit d8d0a0bc)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

4) CVE-2013-4529
hw/pci/pcie_aer.c    pcie aer log can overrun the buffer if log_num is
                     too large

There are two issues in this file:
1. log_max from remote can be larger than on local
then buffer will overrun with data coming from state file.
2. log_num can be larger then we get data corruption
again with an overflow but not adversary controlled.

Fix both issues.
Reported-by: NAnthony Liguori <anthony@codemonkey.ws>
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 5f691ff9)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4527 hw/timer/hpet.c buffer overrun

hpet is a VARRAY with a uint8 size but static array of 32

To fix, make sure num_timers is valid using VMSTATE_VALID hook.
Reported-by: NAnthony Liguori <anthony@codemonkey.ws>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 3f1c49e2)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4526

Within hw/ide/ahci.c, VARRAY refers to ports which is also loaded.  So
we use the old version of ports to read the array but then allow any
value for ports.  This can cause the code to overflow.

There's no reason to migrate ports - it never changes.
So just make sure it matches.
Reported-by: NAnthony Liguori <anthony@codemonkey.ws>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit ae2158ad)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4151 QEMU 1.0 out-of-bounds buffer write in
virtio_load@hw/virtio/virtio.c

So we have this code since way back when:

    num = qemu_get_be32(f);

    for (i = 0; i < num; i++) {
        vdev->vq[i].vring.num = qemu_get_be32(f);

array of vqs has size VIRTIO_PCI_QUEUE_MAX, so
on invalid input this will write beyond end of buffer.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit cc459952)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

CVE-2013-4149 QEMU 1.3.0 out-of-bounds buffer write in
virtio_net_load()@hw/net/virtio-net.c

>         } else if (n->mac_table.in_use) {
>             uint8_t *buf = g_malloc0(n->mac_table.in_use);

We are allocating buffer of size n->mac_table.in_use

>             qemu_get_buffer(f, buf, n->mac_table.in_use * ETH_ALEN);

and read to the n->mac_table.in_use size buffer n->mac_table.in_use *
ETH_ALEN bytes, corrupting memory.

If adversary controls state then memory written there is controlled
by adversary.
Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
(cherry picked from commit 98f93ddd)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>