Stefan Hajnoczi [Wed, 15 Jul 2015 17:16:59 +0000 (18:16 +0100)]
rtl8139: drop tautologous if (ip) {...} statement
The previous patch stopped using the ip pointer as an indicator that the
IP header is present. When we reach the if (ip) {...} statement we know
ip is always non-NULL.
Remove the if statement to reduce nesting.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Stefan Hajnoczi [Wed, 15 Jul 2015 17:16:58 +0000 (18:16 +0100)]
rtl8139: avoid nested ifs in IP header parsing
Transmit offload needs to parse packet headers. If header fields have
unexpected values the offload processing is skipped.
The code currently uses nested ifs because there is relatively little
input validation. The next patches will add missing input validation
and a goto label is more appropriate to avoid deep if statement nesting.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
James Harper [Thu, 30 Oct 2014 10:08:28 +0000 (10:08 +0000)]
fix off-by-one error in pci_piix3_xen_ide_unplug
Fix off-by-one error when unplugging disks, which would otherwise leave the last ATA disk plugged, with obvious consequences. Also rewrite loop to be more readable.
Kevin Wolf [Mon, 27 Jul 2015 03:42:53 +0000 (23:42 -0400)]
ide: Clear DRQ after handling all expected accesses (CVE-2015-5154)
This is additional hardening against an end_transfer_func that fails to
clear the DRQ status bit. The bit must be unset as soon as the PIO
transfer has completed, so it's better to do this in a central place
instead of duplicating the code in all commands (and forgetting it in
some).
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Mon, 27 Jul 2015 03:42:53 +0000 (23:42 -0400)]
ide: Check array bounds before writing to io_buffer (CVE-2015-5154)
If the end_transfer_func of a command is called because enough data has
been read or written for the current PIO transfer, and it fails to
correctly call the command completion functions, the DRQ bit in the
status register and s->end_transfer_func may remain set. This allows the
guest to access further bytes in s->io_buffer beyond s->data_end, and
eventually overflowing the io_buffer.
One case where this currently happens is emulation of the ATAPI command
START STOP UNIT.
This patch fixes the problem by adding explicit array bounds checks
before accessing the buffer instead of relying on end_transfer_func to
function correctly.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Petr Matousek [Sun, 24 May 2015 08:53:44 +0000 (10:53 +0200)]
pcnet: force the buffer access to be in bounds during tx
4096 is the maximum length per TMD and it is also currently the size of
the relay buffer pcnet driver uses for sending the packet data to QEMU
for further processing. With packet spanning multiple TMDs it can
happen that the overall packet size will be bigger than sizeof(buffer),
which results in memory corruption.
Fix this by only allowing to queue maximum sizeof(buffer) bytes.
This is CVE-2015-3209.
Signed-off-by: Petr Matousek <pmatouse@redhat.com> Reported-by: Matt Tait <matttait@google.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Gonglei [Wed, 10 Jun 2015 11:45:19 +0000 (11:45 +0000)]
pcnet: fix Negative array index read
s->xmit_pos maybe assigned to a negative value (-1),
but in this branch variable s->xmit_pos as an index to
array s->buffer. Let's add a check for s->xmit_pos.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:08 +0000 (15:43 +0000)]
xen/pt: unknown PCI config space fields should be read-only
... by default. Add a per-device "permissive" mode similar to pciback's
to allow restoring previous behavior (and hence break security again,
i.e. should be used only for trusted guests).
This is part of XSA-131.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>)
Jan Beulich [Tue, 2 Jun 2015 15:43:08 +0000 (15:43 +0000)]
xen/pt: add a few PCI config space field descriptions
Since the next patch will turn all not explicitly described fields
read-only by default, those fields that have guest writable bits need
to be given explicit descriptors.
Jan Beulich [Tue, 2 Jun 2015 15:43:08 +0000 (15:43 +0000)]
xen/pt: mark reserved bits in PCI config space fields
The adjustments are solely to make the subsequent patches work right
(and hence make the patch set consistent), namely if permissive mode
(introduced by the last patch) gets used (as both reserved registers
and reserved fields must be similarly protected from guest access in
default mode, but the guest should be allowed access to them in
permissive mode).
Jan Beulich [Tue, 2 Jun 2015 15:43:08 +0000 (15:43 +0000)]
xen/pt: mark all PCIe capability bits read-only
xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
only to avoid unintended write-back (just a precaution, the field ought
to be read-only in hardware).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:08 +0000 (15:43 +0000)]
xen/pt: split out calculation of throughable mask in PCI config space handling
This is just to avoid having to adjust that calculation later in
multiple places.
Note that including ->ro_mask in get_throughable_mask()'s calculation
is only an apparent (i.e. benign) behavioral change: For r/o fields it
doesn't matter > whether they get passed through - either the same flag
is also set in emu_mask (then there's no change at all) or the field is
r/o in hardware (and hence a write won't change it anyway).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:07 +0000 (15:43 +0000)]
xen/pt: consolidate PM capability emu_mask
There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
emu_mask variable - we can have the same effect by setting the field
descriptor's emu_mask member suitably right away. Note that
xen_pt_pmcsr_reg_write() is being retained in order to allow later
patches to be less intrusive.
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:07 +0000 (15:43 +0000)]
xen/MSI: don't open-code pass-through of enable bit modifications
Without this the actual XSA-131 fix would cause the enable bit to not
get set anymore (due to the write back getting suppressed there based
on the OR of emu_mask, ro_mask, and res_mask).
Note that the fiddling with the enable bit shouldn't really be done by
qemu, but making this work right (via libxc and the hypervisor) will
require more extensive changes, which can be postponed until after the
security issue got addressed.
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:07 +0000 (15:43 +0000)]
xen/MSI-X: limit error messages
Limit error messages resulting from bad guest behavior to avoid allowing
the guest to cause the control domain's disk to fill.
The first message in pci_msix_write() can simply be deleted, as this
is indeed bad guest behavior, but such out of bounds writes don't
really need to be logged.
The second one is more problematic, as there guest behavior may only
appear to be wrong: For one, the old logic didn't take the mask-all bit
into account. And then this shouldn't depend on host device state (i.e.
the host may have masked the entry without the guest having done so).
Plus these writes shouldn't be dropped even when an entry is unmasked.
Instead, if they can't be made take effect right away, they should take
effect on the next unmasking or enabling operation - the specification
explicitly describes such caching behavior. Until we can validly drop
the message (implementing such caching/latching behavior), issue the
message just once per MSI-X table entry.
Note that the log message in pci_msix_read() similar to the one being
removed here is not an issue: "addr" being of unsigned type, and the
maximum size of the MSI-X table being 32k, entry_nr simply can't be
negative and hence the conditonal guarding issuing of the message will
never be true.
This is XSA-130.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:07 +0000 (15:43 +0000)]
xen: don't allow guest to control MSI mask register
It's being used by the hypervisor. For now simply mimic a device not
capable of masking, and fully emulate any accesses a guest may issue
nevertheless as simple reads/writes without side effects.
This is XSA-129.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Jan Beulich [Tue, 2 Jun 2015 15:43:07 +0000 (15:43 +0000)]
xen: properly gate host writes of modified PCI CFG contents
The old logic didn't work as intended when an access spanned multiple
fields (for example a 32-bit access to the location of the MSI Message
Data field with the high 16 bits not being covered by any known field).
Remove it and derive which fields not to write to from the accessed
fields' emulation masks: When they're all ones, there's no point in
doing any host write.
This fixes a secondary issue at once: We obviously shouldn't make any
host write attempt when already the host read failed.
This is XSA-128.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Petr Matousek [Wed, 6 May 2015 07:48:59 +0000 (09:48 +0200)]
fdc: force the fifo access to be in bounds of the allocated buffer
During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.
Fix this by making sure that the index is always bounded by the
allocated memory.
This is CVE-2015-3456.
Signed-off-by: Petr Matousek <pmatouse@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
Jan Beulich [Tue, 31 Mar 2015 13:58:04 +0000 (13:58 +0000)]
xen: limit guest control of PCI command register
Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses (by disabling memory and/or I/O decoding
and subsequently causing [CPU side] accesses to the respective address
ranges), which (depending on system configuration) may be fatal to the
host.
This is CVE-2015-2756 / XSA-126.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Stefan Hajnoczi [Thu, 5 Mar 2015 11:23:54 +0000 (11:23 +0000)]
dmg: sanitize chunk length and sectorcount (CVE-2014-0145)
Chunk length and sectorcount are used for decompression buffers as well
as the bdrv_pread() count argument. Ensure that they have reasonable
values so neither memory allocation nor conversion from uint64_t to int
will cause problems.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Both compressed and uncompressed I/O is buffered. dmg_open() calculates
the maximum buffer size needed from the metadata in the image file.
There is currently a buffer overflow since ->lengths[] is accounted
against the maximum compressed buffer size but actually uses the
uncompressed buffer:
switch (s->types[chunk]) {
case 1: /* copy */
ret = bdrv_pread(bs->file, s->offsets[chunk],
s->uncompressed_chunk, s->lengths[chunk]);
We must account against the maximum uncompressed buffer size for type=1
chunks.
This patch fixes the maximum buffer size calculation to take into
account the chunk type. It is critical that we update the correct
maximum since there are two buffers ->compressed_chunk and
->uncompressed_chunk.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Thu, 5 Mar 2015 11:11:27 +0000 (11:11 +0000)]
bochs: Use unsigned variables for offsets and sizes (CVE-2014-0147)
Gets us rid of integer overflows resulting in negative sizes which
aren't correctly checked.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Thu, 5 Mar 2015 11:02:27 +0000 (11:02 +0000)]
qcow1: Validate image size (CVE-2014-0223)
A huge image size could cause s->l1_size to overflow. Make sure that
images never require a L1 table larger than what fits in s->l1_size.
This cannot only cause unbounded allocations, but also the allocation of
a too small L1 table, resulting in out-of-bounds array accesses (both
reads and writes).
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Thu, 5 Mar 2015 10:59:35 +0000 (10:59 +0000)]
qcow1: Validate L2 table size (CVE-2014-0222)
Too large L2 table sizes cause unbounded allocations. Images actually
created by qemu-img only have 512 byte or 4k L2 tables.
To keep things consistent with cluster sizes, allow ranges between 512
bytes and 64k (in fact, down to 1 entry = 8 bytes is technically
working, but L2 table sizes smaller than a cluster don't make a lot of
sense).
This also means that the number of bytes on the virtual disk that are
described by the same L2 table is limited to at most 8k * 64k or 2^29,
preventively avoiding any integer overflows.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Benoit Canet <benoit@irqsave.net> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Thu, 5 Mar 2015 10:45:20 +0000 (10:45 +0000)]
qcow2: Don't rely on free_cluster_index in alloc_refcount_block() (CVE-2014-0147)
free_cluster_index is only correct if update_refcount() was called from
an allocation function, and even there it's brittle because it's used to
protect unfinished allocations which still have a refcount of 0 - if it
moves in the wrong place, the unfinished allocation can be corrupted.
So not using it any more seems to be a good idea. Instead, use the
first requested cluster to do the calculations. Return -EAGAIN if
unfinished allocations could become invalid and let the caller restart
its search for some free clusters.
The context of creating a snapsnot is one situation where
update_refcount() is called outside of a cluster allocation. For this
case, the change fixes a buffer overflow if a cluster is referenced in
an L2 table that cannot be represented by an existing refcount block.
(new_table[refcount_table_index] was out of bounds)
[Bump the qemu-iotests 026 refblock_alloc.write leak count from 10 to
11.
--Stefan]
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Thu, 5 Mar 2015 10:42:25 +0000 (10:42 +0000)]
qcow2: Fix NULL dereference in qcow2_open() error path (CVE-2014-0146)
The qcow2 code assumes that s->snapshots is non-NULL if s->nb_snapshots
!= 0. By having the initialisation of both fields separated in
qcow2_open(), any error occuring in between would cause the error path
to dereference NULL in qcow2_free_snapshots() if the image had any
snapshots.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Kevin Wolf [Thu, 5 Mar 2015 10:38:05 +0000 (10:38 +0000)]
qcow2: Fix L1 allocation size in qcow2_snapshot_load_tmp() (CVE-2014-0145)
For the L1 table to loaded for an internal snapshot, the code allocated
only enough memory to hold the currently active L1 table. If the
snapshot's L1 table is actually larger than the current one, this leads
to a buffer overflow.
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Petr Matousek [Mon, 27 Oct 2014 11:41:44 +0000 (12:41 +0100)]
vnc: sanitize bits_per_pixel from the client
bits_per_pixel that are less than 8 could result in accessing
non-initialized buffers later in the code due to the expectation
that bytes_per_pixel value that is used to initialize these buffers is
never zero.
To fix this check that bits_per_pixel from the client is one of the
values that the rfb protocol specification allows.
This is CVE-2014-7815.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
[ kraxel: apply codestyle fix ]
"vmstate_xhci_event" was introduced in commit 37352df3 ("xhci: add live
migration support"), and first released in v1.6.0. The field list in this
VMSD is not terminated with the VMSTATE_END_OF_LIST() macro.
During normal use (ie. migration), the issue is practically invisible,
because the "vmstate_xhci_event" object (with the unterminated field list)
is only ever referenced -- via "vmstate_xhci_intr" -- if xhci_er_full()
returns true, for the "ev_buffer" test. Since that field_exists() check
(apparently) almost always returns false, we almost never traverse
"vmstate_xhci_event" during migration, which hides the bug.
However, Amit's vmstate checker forces recursion into this VMSD as well,
and the lack of VMSTATE_END_OF_LIST() breaks the field list terminator
check (field->name != NULL) in dump_vmstate_vmsd(). The result is
undefined behavior, which in my case translates to infinite recursion
(because the loop happens to overflow into "vmstate_xhci_intr", which then
links back to "vmstate_xhci_event").
Add the missing terminator.
Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Gerd Hoffmann [Mon, 6 Oct 2014 09:42:34 +0000 (11:42 +0200)]
vmware-vga: CVE-2014-3689: turn off hw accel
Quick & easy stopgap for CVE-2014-3689: We just compile out the
hardware acceleration functions which lack sanity checks. Thankfully
we have capability bits for them (SVGA_CAP_RECT_COPY and
SVGA_CAP_RECT_FILL), so guests should deal just fine, in theory.
Subsequent patches will add the missing checks and re-enable the
hardware acceleration emulation.
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Don Koch <dkoch@verizon.com>
Petr Matousek [Thu, 18 Sep 2014 06:35:37 +0000 (08:35 +0200)]
slirp: udp: fix NULL pointer dereference because of uninitialized socket
When guest sends udp packet with source port and source addr 0,
uninitialized socket is picked up when looking for matching and already
created udp sockets, and later passed to sosendto() where NULL pointer
dereference is hit during so->slirp->vnetwork_mask.s_addr access.
Fix this by checking that the socket is not just a socket stub.
This is CVE-2014-3640.
Signed-off-by: Petr Matousek <pmatouse@redhat.com> Reported-by: Xavier Mehrenberger <xavier.mehrenberger@airbus.com> Reported-by: Stephane Duverger <stephane.duverger@eads.net> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-id: 20140918063537.GX9321@dhcp-25-225.brq.redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Related spice-only bug. We have a fixed 16 MB buffer here, being
presented to the spice-server as qxl video memory in case spice is
used with a non-qxl card. It's also used with qxl in vga mode.
When using display resolutions requiring more than 16 MB of memory we
are going to overflow that buffer. In theory the guest can write,
indirectly via spice-server. The spice-server clears the memory after
setting a new video mode though, triggering a segfault in the overflow
case, so qemu crashes before the guest has a chance to do something
evil.
Fix that by switching to dynamic allocation for the buffer.
Gerd Hoffmann [Tue, 26 Aug 2014 13:35:23 +0000 (15:35 +0200)]
vbe: rework sanity checks
Plug a bunch of holes in the bochs dispi interface parameter checking.
Add a function doing verification on all registers. Call that
unconditionally on every register write. That way we should catch
everything, even changing one register affecting the valid range of
another register.
Some of the holes have been added by commit e9c6149f6ae6873f14a12eea554925b6aa4c4dec. Before that commit the
maximum possible framebuffer (VBE_DISPI_MAX_XRES * VBE_DISPI_MAX_YRES *
32 bpp) has been smaller than the qemu vga memory (8MB) and the checking
for VBE_DISPI_MAX_XRES + VBE_DISPI_MAX_YRES + VBE_DISPI_MAX_BPP was ok.
Some of the holes have been there forever, such as
VBE_DISPI_INDEX_X_OFFSET and VBE_DISPI_INDEX_Y_OFFSET register writes
lacking any verification.
Security impact:
(1) Guest can make the ui (gtk/vnc/...) use memory rages outside the vga
frame buffer as source -> host memory leak. Memory isn't leaked to
the guest but to the vnc client though.
(2) Qemu will segfault in case the memory range happens to include
unmapped areas -> Guest can DoS itself.
The guest can not modify host memory, so I don't think this can be used
by the guest to escape.
Correct post load checks:
1. dev->setup_len == sizeof(dev->data_buf)
seems fine, no need to fail migration
2. When state is DATA, passing index > len
will cause memcpy with negative length,
resulting in heap overflow
First of the issues was reported by dgilbert.
Reported-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
ide: Correct improper smart self test counter reset in ide core.
The SMART self test counter was incorrectly being reset to zero,
not 1. This had the effect that on every 21st SMART EXECUTE OFFLINE:
* We would write off the beginning of a dynamically allocated buffer
* We forgot the SMART history
Fix this.
Signed-off-by: Benoit Canet <benoit@irqsave.net>
Message-id: 1397336390-24664-1-git-send-email-benoit.canet@irqsave.net Reviewed-by: Markus Armbruster <armbru@redhat.com> Cc: qemu-stable@nongnu.org Acked-by: Kevin Wolf <kwolf@redhat.com>
[PMM: tweaked commit message as per suggestions from Markus] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
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: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
--
v2: use %ix and %zx to print config_len values Signed-off-by: Juan Quintela <quintela@redhat.com>
When VM guest programs multicast addresses for
a virtio net card, it supplies a 32 bit
entries counter for the number of addresses.
These addresses are read into tail portion of
a fixed macs array which has size MAC_TABLE_ENTRIES,
at offset equal to in_use.
To avoid overflow of this array by guest, qemu attempts
to test the size as follows:
- if (in_use + mac_data.entries <= MAC_TABLE_ENTRIES) {
however, as mac_data.entries is uint32_t, this sum
can overflow, e.g. if in_use is 1 and mac_data.entries
is 0xffffffff then in_use + mac_data.entries will be 0.
Qemu will then read guest supplied buffer into this
memory, overflowing buffer on heap.
CVE-2014-0150
Cc: qemu-stable@nongnu.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 1397218574-25058-1-git-send-email-mst@redhat.com Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Conflicts:
hw/net/virtio-net.c
Jeff Cody [Wed, 26 Mar 2014 12:05:39 +0000 (13:05 +0100)]
vhdx: Bounds checking for block_size and logical_sector_size (CVE-2014-0148)
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: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Michael Roth [Thu, 3 Apr 2014 16:51:46 +0000 (19:51 +0300)]
virtio: avoid buffer overrun on incoming migration
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: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Juan Quintela <quintela@redhat.com>
vmxnet3: validate queues configuration read on migration
CVE-2013-4544
Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> Reported-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 1396604722-11902-5-git-send-email-dmitry@daynix.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
vmxnet3: validate interrupt indices read on migration
CVE-2013-4544
Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> Reported-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 1396604722-11902-4-git-send-email-dmitry@daynix.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
vmxnet3: validate queues configuration coming from guest
CVE-2013-4544
Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> Reported-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 1396604722-11902-3-git-send-email-dmitry@daynix.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
vmxnet3: validate interrupt indices coming from guest
CVE-2013-4544
Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> Reported-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 1396604722-11902-2-git-send-email-dmitry@daynix.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Conflicts:
hw/net/vmxnet3.c
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: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
usb: sanity check setup_index+setup_len in post_load
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: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Cc: Amit Shah <amit.shah@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
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: Anthony Liguori <anthony@codemonkey.ws> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
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: Anthony Liguori <anthony@codemonkey.ws> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Juan Quintela <quintela@redhat.com>
virtio: out-of-bounds buffer write on invalid state load
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: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
virtio-net: out-of-bounds buffer write on invalid state load
CVE-2013-4150 QEMU 1.5.0 out-of-bounds buffer write in
virtio_net_load()@hw/net/virtio-net.c
This code is in hw/net/virtio-net.c:
if (n->max_queues > 1) {
if (n->max_queues != qemu_get_be16(f)) {
error_report("virtio-net: different max_queues ");
return -1;
}
n->curr_queues = qemu_get_be16(f);
for (i = 1; i < n->curr_queues; i++) {
n->vqs[i].tx_waiting = qemu_get_be32(f);
}
}
Number of vqs is max_queues, so if we get invalid input here,
for example if max_queues = 2, curr_queues = 3, we get
write beyond end of the buffer, with data that comes from
wire.
This might be used to corrupt qemu memory in hard to predict ways.
Since we have lots of function pointers around, RCE might be possible.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
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: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
with good in_use value, "n->mac_table.in_use * ETH_ALEN" can get
positive and bigger than mac_table.macs. For example 0x81000000
satisfies this condition when ETH_ALEN is 6.
Fix it by making the value unsigned.
For consistency, change first_multi as well.
Note: all call sites were audited to confirm that
making them unsigned didn't cause any issues:
it turns out we actually never do math on them,
so it's easy to validate because both values are
always <= MAC_TABLE_ENTRIES.
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
Roger Pau Monne [Thu, 13 Nov 2014 17:42:09 +0000 (18:42 +0100)]
xen_disk: fix unmapping of persistent grants
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Keep track of memory regions where persistent grants have been mapped
since we need to unmap them as a whole. It is not possible to unmap a
single grant if it has been batch-mapped. A new check has also been added
to make sure persistent grants are only used if the whole mapped region
can be persistently mapped in the batch_maps case.
- Unmap persistent grants before switching to the closed state, so the
frontend can also free them.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reported-by: George Dunlap <george.dunlap@eu.citrix.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: George Dunlap <george.dunlap@eu.citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
breaks Xen support in QEMU, in particular the Xen mapcache. The effect
is that one Windows XP installation out of ten would end up with BSOD.
The reason is that after this commit l in address_space_rw can span a
page boundary, however qemu_get_ram_ptr still calls xen_map_cache asking
to map a single page (if block->offset == 0).
Fix the issue by reverting to the previous behaviour: do not return a
length from address_space_translate_internal that can span a page
boundary.
Also in address_space_translate do not ignore the length returned by
address_space_translate_internal.
Anthony PERARD [Fri, 10 Jan 2014 15:56:33 +0000 (15:56 +0000)]
xen_pt: Fix passthrough of device with ROM.
QEMU does not need and should not allocate memory for the ROM of a
passthrough PCI device. So this patch initialize the particular region
like any other PCI BAR of a passthrough device.
When a guest will access the ROM, Xen will take care of the IO, QEMU
will not be involved in it.
Xen set a limit of memory available for each guest, allocating memory
for a ROM can hit this limit.
pci: Replace pci_find_domain() with more general pci_root_bus_path()
The issue is that i440fx savevm idstr went from 0000:00:00.0/I440FX to
0000:00.0/I440FX. Unfortunately we are stuck with the breakage for
1.6 machine types.
Add a compat property to maintain the busted idstr for the 1.6 machine
types, but revert to the old style format for 1.7+, and <= 1.5.
Tested with migration from qemu 1.5, qemu 1.6, and qemu.git.
Cc: qemu-stable@nongnu.org Signed-off-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Conflicts:
include/hw/i386/pc.h
Laszlo Ersek [Sat, 2 Nov 2013 19:14:21 +0000 (20:14 +0100)]
scsi_target_send_command(): amend stable-1.6 port of the CVE-2013-4344 fix
The originally suggested fix for CVE-2013-4344 introduced a regression in
scsi_target_send_command() / REQUEST_SENSE; the third argument passed to
scsi_device_get_sense() -- for the "len" parameter -- ignored the
possibility of the guest SCSI driver requesting truncated (or shorter than
full) sense data.
This could result in (r->len > req->cmd.xfer) on return, which is not
valid SCSI.
The problem was addressed in the second round, and the commit on the
master branch (84642435) is correct. However the stable-1.6 branch (the
v1.6.1 release) has the original, regressive fix (commit fdcbe7d5); let's
update it.
Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Petar Jovanovic [Fri, 29 Nov 2013 16:27:42 +0000 (17:27 +0100)]
target-mips: fix 64-bit FPU config for user-mode emulation
FR bit should be initialized to 1 for MIPS64, under condition that this
bit is writable and that CPU has an FPU unit. It should be initialized to
zero for MIPS32.
This fixes different MIPS32 issues with FPU instructions whose behaviour
defaulted to 64-bit FPU mode.
Signed-off-by: Petar Jovanovic <petar.jovanovic@imgtec.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
(cherry picked from commit 4d66261f71f2efa31e1052e4041c5ee505572fe5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fam Zheng [Tue, 3 Dec 2013 02:41:05 +0000 (10:41 +0800)]
vmdk: Fix creating big description file
The buffer for description file was 4096 which only covers a few
hundred of extents. This changes the buffer to dynamic allocated with
g_strdup_printf in order to support bigger cases.
Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit af057fe74092df2e7a576448ddbdc0daac1370bf)
Kevin Wolf [Wed, 4 Dec 2013 10:06:36 +0000 (11:06 +0100)]
qcow2: Zero-initialise first cluster for new images
Strictly speaking, this is only required for has_zero_init() == false,
but it's easy enough to just do a cluster-aligned write that is padded
with zeros after the header.
This fixes that after 'qemu-img create' header extensions are attempted
to be parsed that are really just random leftover data.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit f8413b3c23b08a547ce18609acc6fae5fd04ed5c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Fri, 6 Dec 2013 18:16:40 +0000 (11:16 -0700)]
vfio-pci: Release all MSI-X vectors when disabled
We were relying on msix_unset_vector_notifiers() to release all the
vectors when we disable MSI-X, but this only happens when MSI-X is
still enabled on the device. Perform further cleanup by releasing
any remaining vectors listed as in-use after this call. This caused
a leak of IRQ routes on hotplug depending on how the guest OS prepared
the device for removal.
Bandan Das [Wed, 6 Nov 2013 22:52:17 +0000 (17:52 -0500)]
pci: unregister vmstate_pcibus on unplug
PCIBus registers a vmstate during init. Unregister it upon
removal/unplug.
Signed-off-by: Bandan Das <bsd@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5c397242d5d53c1adecce31817bb439383cf8228)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Tue, 10 Sep 2013 16:21:08 +0000 (18:21 +0200)]
qdev-monitor: Unref device when device_add fails
qdev_device_add() leaks the created device upon failure. I suspect this
problem crept in because qdev_free() unparents the device but does not
drop a reference - confusing name.
Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit ee6abeb6ec08473713848ce9028110f1684853b7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Igor Mammedov [Tue, 17 Sep 2013 13:32:32 +0000 (15:32 +0200)]
qdev-monitor: Fix crash when device_add is called with abstract driver
User is able to crash running QEMU when following monitor
command is called:
device_add intel-hda-generic
Crash is caused by assertion in object_initialize_with_type()
when type is abstract.
Checking if type is abstract before instance is created in
qdev_device_add() allows to prevent crash on incorrect user input.
Cc: qemu-stable@nongnu.org Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 2fa4e56d88aa0039062bbc7f9a88e9f90c77ed94)
Conflicts:
qdev-monitor.c
*updated to reflect different 1.6 variable names
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Amos Kong [Mon, 18 Nov 2013 15:32:17 +0000 (23:32 +0800)]
virtio-net: fix the memory leak in rxfilter_notify()
object_get_canonical_path() returns a gchar*, it should be freed by the
caller.
Signed-off-by: Amos Kong <akong@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Vlad Yasevich <vyasevic@redhat.com> Reviewed-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 96e35046e4a97df5b4e1e24e217eb1e1701c7c71)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Tue, 12 Nov 2013 18:53:24 +0000 (11:53 -0700)]
vfio-pci: Fix multifunction=on
When an assigned device is initialized it copies the device config
space into the emulated config space. Unfortunately multifunction is
setup prior to the device initfn and gets clobbered. We need to
restore it just like pci-assign does.
Cc: qemu-stable@nongnu.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 8d07d6c46597a885eb38d99cc6fff399ce69cd21)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Lieven [Tue, 12 Nov 2013 12:48:07 +0000 (13:48 +0100)]
qcow2: fix possible corruption when reading multiple clusters
if multiple sectors spanning multiple clusters are read the
function count_contiguous_clusters should ensure that the
cluster type should not change between the clusters.
Especially the for-loop should break when we have one
or more normal clusters followed by a compressed cluster.
Unfortunately the wrong macro was used in the mask to
compare the flags.
This was discovered while debugging a data corruption
issue when converting a compressed qcow2 image to raw.
qemu-img reads 2MB chunks which span multiple clusters.
CC: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 78a52ad5acca7053b774fcc80290e7b7e224c80a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Fri, 27 Sep 2013 10:14:15 +0000 (12:14 +0200)]
qcow2: count_contiguous_clusters and compression
The function is not intended to be used on compressed clusters and will
not work correctly, if used anyway, since L2E_OFFSET_MASK is not the
right mask for determining the offset of compressed clusters. Therefore,
assert that the first cluster is not compressed and always include the
compression flag in the mask of significant flags, i.e., stop the search
as soon as a compressed cluster occurs.
pci: Replace pci_find_domain() with more general pci_root_bus_path()
The issue is that i440fx savevm idstr went from 0000:00:00.0/I440FX to
0000:00.0/I440FX. Unfortunately we are stuck with the breakage for
1.6 machine types.
Add a compat property to maintain the busted idstr for the 1.6 machine
types, but revert to the old style format for 1.7+, and <= 1.5.
Tested with migration from qemu 1.5, qemu 1.6, and qemu.git.
Cc: qemu-stable@nongnu.org Signed-off-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 04c7d8b8dea724f1007f0f6e76047ff03b4cb24f)
Conflicts:
include/hw/i386/pc.h
*removed 1.6 compat properties
*enabled short_root_bus by default to enable for 1.6 (no 1.6 compat
fields to do so in 1.6.x)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
which happens due to attempt to invalidate breakpoint by virtual address
for which get_phys_page_debug couldn't find mapping.
For more details see
http://lists.nongnu.org/archive/html/qemu-devel/2013-09/msg04582.html
Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit e8262a1b5b7cfbcbc80c46e4ce6ff7c517b7b2f6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 6 Nov 2013 08:58:08 +0000 (16:58 +0800)]
virtio-net: only delete bh that existed
We delete without check whether it existed during exit. This will lead NULL
pointer deference since it was created conditionally depends on guest driver
status and features. So add a check of existence before trying to delete it.
Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 1383728288-28469-1-git-send-email-jasowang@redhat.com Signed-off-by: Anthony Liguori <aliguori@amazon.com>
(cherry picked from commit fe2dafa02de4f80ab36f6e0f4ddfcd6418c03c49)
Conflicts:
hw/net/virtio-net.c
*modified to reflect timer function names for 1.6
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Weil [Wed, 30 Oct 2013 21:52:24 +0000 (22:52 +0100)]
linux-user: Fix stat64 syscall for SPARC64
Some targets use a stat64 structure for the stat64 syscall while others
use a stat structure. SPARC64 used the wrong kind.
Instead of extending the conditional compilation in syscall.c, now a
macro TARGET_HAS_STRUCT_STAT64 is defined whenever a target has a
target_stat64.
Signed-off-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Erik de Castro Lopo <erikd@mega-nerd.com>
(cherry picked from commit 20d155bc902f41c5b354937e730ad85b43614ae9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Mon, 21 Oct 2013 20:03:06 +0000 (21:03 +0100)]
configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
Our rules.mak adds '-rR' to MAKEFLAGS to indicate that we will be
explicitly specifying everything and not relying on any default
variables or rules. However we were accidentally relying on the
default ARFLAGS ("rv"). This went unnoticed because of a bug in
GNU Make 3.82 and earlier which meant that adding -rR to MAKEFLAGS
only affected submakes, not the currently running instance.
Explicitly set ARFLAGS in config-host.mak, in the same way we
handle CFLAGS and LDFLAGS; this will allow us to work with
Make 4.0.
Thanks to Paul Smith for analyzing this bug for us.
Cc: qemu-stable@nongnu.org Reported-by: Ken Moffat <zarniwhoop@ntlworld.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 45d285abd7028ac72418c1a22f9298bb898fbfb8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Mike Frysinger [Mon, 1 Jul 2013 03:30:18 +0000 (23:30 -0400)]
configure: detect endian via compile test
This avoids needing to execute a program and keeping an (incomplete)
list when cross-compiling.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Tested-by: James Hogan <james.hogan@imgtec.com> [mips]
Message-id: 1372649418-4987-1-git-send-email-vapier@gentoo.org Signed-off-by: Anthony Liguori <aliguori@amazon.com>
(cherry picked from commit 61cc919f73ea7ca134c0ac41b748981ad63a253b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini [Wed, 16 Oct 2013 17:17:08 +0000 (19:17 +0200)]
monitor: eliminate monitor_event_state_lock
This lock does not protect anything that the BQL does not already
protect. Furthermore, with -nodefaults and no monitor, the mutex
is not initialized but monitor_protocol_event_queue is called
anyway, which causes a crash under mingw (and only works by luck.
under Linux or other POSIX OSes).
Reported-by: Orx Goshen <orx.goshen@intel.com> Cc: Daniel Berrange <berrange@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
(cherry picked from commit c20b7fa4b2fedd979bcb0cc974bb5d08a10e3448)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Hans de Goede [Wed, 9 Oct 2013 19:33:44 +0000 (21:33 +0200)]
audio: honor QEMU_AUDIO_TIMER_PERIOD instead of waking up every *nano* second
Now that we no longer have MIN_REARM_TIMER_NS a bug in the audio subsys has
clearly shown it self by trying to make a timer fire every nano second.
Note we have a similar problem in 1.6, 1.5 and older but there
MIN_REARM_TIMER_NS limits the wakeups caused by audio being active to
4000 times / second. This still causes a host cpu load of 50 % for simply
playing audio, where as with this patch git master is at 13%, so we should
backport this to 1.5 and 1.6 too.
Note this will not apply to 1.5 and 1.6 as is.
Cc: qemu-stable@nongnu.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit b4350deed67b95651896ddb60cf9f765093a4848)
Conflicts:
audio/audio.c
*fixed to reflect 1.6 timer function/clock names
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fam Zheng [Fri, 11 Oct 2013 11:48:29 +0000 (19:48 +0800)]
vmdk: Fix vmdk_parse_extents
An extra 'p++' after while loop when *p == '\n' will move p to unknown
data position, risking parsing junk data or memory access violation.
Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 899f1ae219d5eaa96a53c996026cb0178d62a86d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Matthew Daley [Thu, 10 Oct 2013 14:10:48 +0000 (14:10 +0000)]
xen_disk: mark ioreq as mapped before unmapping in error case
Commit 4472beae modified the semantics of ioreq_{un,}map so that they are
idempotent if called when they're not needed (ie., twice in a row). However,
it neglected to handle the case where batch mapping is not being used (the
default), and one of the grants fails to map. In this case, ioreq_unmap will
be called to unwind and unmap any mappings already performed, but ioreq_unmap
simply returns due to the aforementioned change (the ioreq has not already
been marked as mapped).
The frontend user can therefore force xen_disk to leak grant mappings, a
per-domain limited resource.
Fix by marking the ioreq as mapped before calling ioreq_unmap in this
situation.
Signed-off-by: Matthew Daley <mattjd@gmail.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
(cherry picked from commit a76f48e53382e6f039db6278443e3ce437653302)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Weil [Mon, 30 Sep 2013 21:04:49 +0000 (23:04 +0200)]
qemu-char: Fix potential out of bounds access to local arrays
Latest gcc-4.8 supports a new option -fsanitize=address which activates
an AddressSanitizer. This AddressSanitizer stops the QEMU system emulation
very early because two character arrays of size 8 are potentially written
with 9 bytes.
There is no obvious reason why width or height could need 8 characters,
so reduce it to 7 characters which together with the terminating '\0'
fit into the arrays.
Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Alex Bennée <alex@bennee.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 49aa4058ac6dd0081aaa45776f07c98df397ca5e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
projects / qemu-upstream-4.4-testing.git / log