curl_read_cb is callback function for libcurl when data arrives. The
data size passed in here is not guaranteed to be within the range of
request we submitted, so we may overflow the guest IO buffer. Check the
real size we have before memcpy to buffer to avoid overflow.
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-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 6d4b9e55)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Other variables (e.g. sectors_per_block) are calculated using these
variables, and if not range-checked illegal values could be obtained
causing infinite loops and other potential issues when calculating
BAT entries.

The 1.00 VHDX spec requires BlockSize to be min 1MB, max 256MB.
LogicalSectorSize is required to be either 512 or 4096 bytes.
Reported-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NJeff Cody <jcody@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 1d7678de)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The maximum blocks_in_image is 0xffffffff / 4, which also limits the
maximum disk_size for a VDI image to 1024TB.  Note that this is the maximum
size that QEMU will currently support with this driver, not necessarily the
maximum size allowed by the image format.

This also fixes an incorrect error message, a bug introduced by commit
5b7aa9b5 (Reported by Stefan Weil)
Signed-off-by: NJeff Cody <jcody@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 63fa06dc)

Conflicts:
	block/vdi.c

*modified to retain 1.7's usage of logout() over error_setg()
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This fixes some cases of division by zero crashes.
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 5e71dfad)

Conflicts:
	tests/qemu-iotests/group

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

This adds checks to make sure that max_table_entries and block_size
are in sane ranges.  Memory is allocated based on max_table_entries,
and block_size is used to calculate indices into that allocated
memory, so if these values are incorrect that can lead to potential
unbounded memory allocation, or invalid memory accesses.

Also, the allocation of the pagetable is changed from g_malloc0()
to qemu_blockalign().
Signed-off-by: NJeff Cody <jcody@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 97f1c45c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

32 bit truncation could let us access the wrong offset in the image.
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 a9ba36a4)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This fixes two possible division by zero crashes: In bochs_open() and in
seek_to_sector().
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 8e53abbc)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

It should neither become negative nor allow unbounded memory
allocations. This fixes aborts in g_malloc() and an s->catalog_bitmap
buffer overflow on big endian hosts.
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 e3737b82)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Gets us rid of integer overflows resulting in negative sizes which
aren't correctly checked.
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 246f6583)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This is an on-disk structure, so offsets must be accurate.

Before this patch, sizeof(bochs) != sizeof(header_v1), which makes the
memcpy() between both invalid. We're lucky enough that the destination
buffer happened to be the larger one, and the memcpy size to be taken
from the smaller one, so we didn't get a buffer overflow in practice.

This patch unifies the both structures, eliminating the need to do a
memcpy in the first place. The common fields are extracted to the top
level of the struct and the actually differing part gets a union of the
two versions.
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 3dd8a676)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

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>