- Aug 10, 2015
-
-
-
Paolo Bonzini authored
Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9172f428) Signed-off-by:
Michael Roth <mdroth@linux.vnet.ibm.com>
-
- Aug 04, 2015
-
-
Stefan Hajnoczi authored
The TCP Data Offset field contains the length of the header. Make sure it is valid and does not exceed the IP data length. Reported-by:
朱东海(启路) <donghai.zdh@alibaba-inc.com> Reviewed-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 8357946b) Signed-off-by:
-
Stefan Hajnoczi authored
TCP Large Segment Offload accesses the TCP header in the packet. If the packet is too short we must not attempt to access header fields: tcp_header *p_tcp_hdr = (tcp_header*)(eth_payload_data + hlen); int tcp_hlen = TCP_HEADER_DATA_OFFSET(p_tcp_hdr); Reported-by:
-
Stefan Hajnoczi authored
The IP Total Length field includes the IP header and data. Make sure it is valid and does not exceed the Ethernet payload size. Reported-by:
-
Stefan Hajnoczi authored
The IP Header Length field was only checked in the IP checksum case, but is used in other cases too. Reported-by:
-
Stefan Hajnoczi authored
Transmit offload features access Ethernet and IP headers the packet. If the packet is too short we must not attempt to access header fields: int proto = be16_to_cpu(*(uint16_t *)(saved_buffer + 12)); ... eth_payload_data = saved_buffer + ETH_HLEN; ... ip = (ip_header*)eth_payload_data; if (IP_HEADER_VERSION(ip) != IP_HEADER_VERSION_4) { Reported-by: -
Stefan Hajnoczi authored
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. Reported-by: -
Stefan Hajnoczi authored
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. Reported-by:
-
Aurelien Jarno authored
The add2 code in the tcg_out_addsub2 function doesn't take into account the case where rl == al == bl. In that case we can't compute the carry after the addition. As it corresponds to a multiplication by 2, the carry bit is the bit 31. While this is a corner case, this prevents x86-64 guests to boot on a MIPS host. Cc: qemu-stable@nongnu.org Reviewed-by:
Richard Henderson <rth@twiddle.net> Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit c99d6969) Signed-off-by:
-
Aurelien Jarno authored
For 32-bit guest, we load a 32-bit address from the TLB, so there is no need to compensate for the low or high part. This fixes 32-bit guests on big-endian hosts. Cc: qemu-stable@nongnu.org Reviewed-by:
-
Stefano Stabellini authored
pci_piix3_xen_ide_unplug should completely unhook the unplugged IDEDevice from the corresponding BlockBackend, otherwise the next call to release_drive will try to detach the drive again. Suggested-by:
Kevin Wolf <kwolf@redhat.com> Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> (cherry picked from commit 6cd38783) Signed-off-by:
-
- Jul 30, 2015
-
-
Kevin Wolf authored
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:
John Snow <jsnow@redhat.com> (cherry picked from commit cb72cba8) Signed-off-by:
-
Kevin Wolf authored
The command must be completed on all code paths. START STOP UNIT with pwrcnd set should succeed without doing anything. Signed-off-by:
-
Kevin Wolf authored
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:
-
Jeff Cody authored
This checks that VPC is able to successfully fail (without segfault) on an image file with a max_table_entries that exceeds 0x40000000. This table entry is within the valid range for VPC (although too large for this sample image). Cc: qemu-stable@nongnu.org Signed-off-by:
Jeff Cody <jcody@redhat.com> Signed-off-by:
-
Jeff Cody authored
When we allocate the pagetable based on max_table_entries, we multiply the max table entry value by 4 to accomodate a table of 32-bit integers. However, max_table_entries is a uint32_t, and the VPC driver accepts ranges for that entry over 0x40000000. So during this allocation: s->pagetable = qemu_try_blockalign(bs->file, s->max_table_entries * 4); The size arg overflows, allocating significantly less memory than expected. Since qemu_try_blockalign() size argument is size_t, cast the multiplication correctly to prevent overflow. The value of "max_table_entries * 4" is used elsewhere in the code as well, so store the correct value for use in all those cases. We also check the Max Tables Entries value, to make sure that it is < SIZE_MAX / 4, so we know the pagetable size will fit in size_t. Cc: qemu-stable@nongnu.org Reported-by:
Richard W.M. Jones <rjones@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
This is a guest-triggerable buffer overflow present in QEMU 2.2.0 and newer. scsi_cdb_length returns -1 as an error value, but the caller does not check it. Luckily, the massive overflow means that QEMU will just SIGSEGV, making the impact much smaller. Reported-by:
Fam Zheng <famz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by:
-
Alex Williamson authored
bootindex was incorrectly changed to a device Property during the platform code split, resulting in it no longer working. Remove it. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Cc: qemu-stable@nongnu.org # v2.3+ (cherry picked from commit 759b484c) Signed-off-by:
-
Jason Wang authored
Commit 032a74a1 ("virtio-net: byteswap virtio-net header") breaks any layout by requiring out_sg[0].iov_len >= n->guest_hdr_len. Fixing this by copying header to temporary buffer if swap is needed, and then use this buffer as part of out_sg. Fixes 032a74a1 ("virtio-net: byteswap virtio-net header") Cc: qemu-stable@nongnu.org Cc: clg@fr.ibm.com Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Eric Blake <eblake@redhat.com> (cherry picked from commit feb93f36) Signed-off-by:
-
Alex Williamson authored
The RTL8168 quirk correctly describes using bit 31 as a signal to mark a latch/completion, but the code mistakenly uses bit 28. This causes the Realtek driver to spin on this register for quite a while, 20k cycles on Windows 7 v7.092 driver. Then it gets frustrated and tries to set the bit itself and spins for another 20k cycles. For some this still results in a working driver, for others not. About the only thing the code really does in its current form is protect the guest from sneaking in writes to the real hardware MSI-X table. The fix is obviously to use bit 31 as we document that we should. The other problem doesn't seem to affect current drivers as nobody seems to use these window registers for writes to the MSI-X table, but we need to use the stored data when a write is triggered, not the value of the current write, which only provides the offset. Note that only the Windows drivers from Realtek seem to use these registers, the Microsoft drivers provided with Windows 8.1 do not access them, nor do Linux in-kernel drivers. Link: https://bugs.launchpad.net/qemu/+bug/1384892 Signed-off-by:
-
James Hogan authored
In case we're running on a 64-bit host, be sure to sign extend the general purpose registers and hi/lo/pc before writing them to KVM, so as to take advantage of MIPS32/MIPS64 compatibility. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Leon Alrae <leon.alrae@imgtec.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: kvm@vger.kernel.org Cc: qemu-stable@nongnu.org Message-Id: <1429871214-23514-3-git-send-email-james.hogan@imgtec.com> Signed-off-by:
-
James Hogan authored
Fix access to 32-bit registers on big endian targets. The pointer passed to the kernel must be for the actual 32-bit value, not a temporary 64-bit value, otherwise on big endian systems the kernel will only interpret the upper half. Signed-off-by:
-
Fam Zheng authored
Cc: qemu-stable@nongnu.org Signed-off-by:
-
Wenshuang Ma authored
Last month, we experienced several guests crash(6cores-8cores), qemu logs display the following messages: qemu-system-x86_64: /build/qemu-2.1.2/kvm-all.c:976: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. After analysis and verification, we can confirm it's irq-balance daemon(in guest) leads to the assertion failure. Start a 8 core guest with two disks, execute the following scripts will reproduce the BUG quickly: irq_affinity.sh ======================================================================== vda_irq_num=25 vdb_irq_num=27 while [ 1 ] do for irq in {1,2,4,8,10,20,40,80} do echo $irq > /proc/irq/$vda_irq_num/smp_affinity echo $irq > /proc/irq/$vdb_irq_num/smp_affinity dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct done done ======================================================================== QEMU setup static irq route entries in kvm_pc_setup_irq_routing(), PIC and IOAPIC share the first 15 GSI numbers, take up 23 GSI numbers, but take up 38 irq route entries. When change irq smp_affinity in guest, a dynamic route entry may be setup, the current logic is: if allocate GSI number succeeds, a new route entry can be added. The available dynamic GSI numbers is 1021(KVM_MAX_IRQ_ROUTES-23), but available irq route entries is only 986(KVM_MAX_IRQ_ROUTES-38), GSI numbers greater than route entries. irq-balance's behavior will eventually leads to total irq route entries exceed KVM_MAX_IRQ_ROUTES, ioctl(KVM_SET_GSI_ROUTING) fail and kvm_irqchip_commit_routes() trigger assertion failure. This patch fix the BUG. Signed-off-by:Wenshuang Ma <kevinnma@tencent.com> Cc: qemu-stable@nongnu.org Signed-off-by:
-
Michael Roth authored
Current PPC code relies on -mem-path being used in order for hugepage support to be detected. With the introduction of MemoryBackendFile we can now handle this via: -object memory-file-backend,mem-path=...,id=hugemem0 \ -numa node,id=mem0,memdev=hugemem0 Management tools like libvirt treat the 2 approaches as interchangeable in some cases, which can lead to user-visible regressions even for previously supported guest configurations. Fix these by also iterating through any configured memory backends that may be backed by hugepages. Since the old code assumed hugepages always backed the entirety of guest memory, play it safe an pick the minimum across the max pages sizes for all backends, even ones that aren't backed by hugepages. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Alexander Graf <agraf@suse.de> (cherry picked from commit 2d103aae) Conflicts: target-ppc/kvm.c *remove context dependency on header includes not in 2.3.0 Signed-off-by:
-
David Gibson authored
If a guest passes the reg property of a valid VIO object that is not a VTY to either H_GET_TERM_CHAR or H_PUT_TERM_CHAR, QEMU hits a dynamic cast assertion and aborts. PAPR+ says "Hypervisor checks the termno parameter for validity against the Vterm IOA unit addresses assigned to the partition, else return H_Parameter." This patch adds a type check to ensure vty_lookup() either returns a pointer to a valid VTY object or NULL. H_GET_TERM_CHAR and H_PUT_TERM_CHAR will now return H_PARAMETER to the guest instead of crashing. The patch has no effect on the reg == 0 hack used to implement the RTAS call display-character. Signed-off-by:
Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by:
-
Christian Borntraeger authored
commit fa92e218 ("s390x/ipl: avoid sign extension") introduced a regression: qemu-system-s390x -drive file=image.qcow,format=qcow2 does not boot, the bios states "No virtio-blk device found!" adding bootindex=1 does boot. The reason is that the uint32_t as return value will not do the right thing for the return -1 (default without bootindex). The bios itself, will interpret a 64bit -1 as autodetect (but it will interpret 32bit -1 as ccw device address ff.ff.ffff) Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: qemu-stable@nongnu.org # v2.3.0 Tested-by:
Cornelia Huck <cornelia.huck@de.ibm.com> (cherry picked from commit 6efd2c2a) Signed-off-by:
-
Peter Lieven authored
a malicious caller could otherwise specify a very large value via the URI and force libnfs to allocate a large amount of memory for the readahead buffer. Cc: qemu-stable@nongnu.org Signed-off-by:
Peter Lieven <pl@kamp.de> Message-id: 1435317241-25585-1-git-send-email-pl@kamp.de Signed-off-by:
-
John Snow authored
A filter is added to allow callers to request very specific events to be pulled from the event queue, while leaving undesired events still in the stream. This allows us to poll for completion data for multiple asynchronous events in any arbitrary order. A new timeout context is added to the qmp pull_event method's wait parameter to allow tests to fail if they do not complete within some expected period of time. Also fixed is a bug in qmp.pull_event where we try to retrieve an event from an empty list if we attempt to retrieve an event with wait=False but no events have occurred. Signed-off-by:
Max Reitz <mreitz@redhat.com> Reviewed-by:
-
Fam Zheng authored
Only poll the specific type of event we are interested in, to avoid stealing events that should be consumed by someone else. Suggested-by:
-
Fam Zheng authored
This checks that the discard on mirror source that effectively zeroes data is also reflected by the data of target. Signed-off-by:
-
Fam Zheng authored
Signed-off-by:
-
Fam Zheng authored
Unsetting dirty globally with discard is not very correct. The discard may zero out sectors (depending on can_write_zeroes_with_unmap), we should replicate this change to destination side to make sure that the guest sees the same data. Calling bdrv_reset_dirty also troubles mirror job because the hbitmap iterator doesn't expect unsetting of bits after current position. So let's do it the opposite way which fixes both problems: set the dirty bits if we are to discard it. Reported-by:
<wangxiaolong@ucloud.cn> Signed-off-by:
-
Fam Zheng authored
If guest discards a source cluster, mirroring with bdrv_aio_readv is overkill. Some protocols do zero upon discard, where it's best to use bdrv_aio_write_zeroes, otherwise, bdrv_aio_discard will be enough. Signed-off-by:
-
Fam Zheng authored
If specified as "true", it allows discarding on target sectors where source is not allocated. Signed-off-by:
-
Fam Zheng authored
Like bdrv_is_allocated_above, this function follows the backing chain until seeing BDRV_BLOCK_ALLOCATED. Base is not included. Reimplement bdrv_is_allocated on top. [Initialized bdrv_co_get_block_status_above() ret to 0 to silence mingw64 compiler warning about the unitialized variable. assert(bs != base) prevents that case but I suppose the program could be compiled with -DNDEBUG. --Stefan] Signed-off-by:
-
Cornelia Huck authored
For a guest-initiated reset, we need to not only reset the virtio device, but also reset the VirtioCcwDevice into a clean state. This includes resetting the indicators, or else a guest will not be able to e.g. switch from classic interrupts to adapter interrupts. Split off this routine into a new function virtio_ccw_reset_virtio() to make the distinction between resetting the virtio-related devices and the base subchannel device clear. CC: qemu-stable@nongnu.org Signed-off-by:
-
Jason Wang authored
We override the error value r in fail_vq, this will cause the caller can't detect the failure which may cause the caller may disable the notifiers twice if vhost is failed to start. Fix this by using another variable to keep track the return value of set_host_notifier(). Fixes b0b3db79 ("vhost-net: cleanup host notifiers at last step") Cc: qemu-stable@nongnu.org Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Laszlo Ersek authored
This is done mainly for improving readability, and in preparation for the next patch, but Markus pointed out another bonus for the string being returned: "No arbitrary length limit. Before the patch, it's 39 characters, and the code breaks catastrophically when qdev_fw_name() is longer: the second snprintf() is called with its first argument pointing beyond path[], and its second argument underflowing to a huge size." Cc: qemu-stable@nongnu.org Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Tested-by:
Marcel Apfelbaum <marcel@redhat.com> Reviewed-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
-
