When processing 'sendkey' command, hmp_sendkey routine null
terminates the 'keyname_buf' array. This results in an OOB
write issue, if 'keyname_len' was to fall outside of
'keyname_buf' array.

Since the keyname's length is known the keyname_buf can be
removed altogether by adding a length parameter to
index_from_key() and using it for the error output as well.
Reported-by: NLing Liu <liuling-it@360.cn>
Signed-off-by: NWolfgang Bumiller <w.bumiller@proxmox.com>
Message-Id: <20160113080958.GA18934@olga>
[Comparison with "<" dumbed down, test for junk after strtoul()
tweaked]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

(cherry picked from commit 64ffbe04)

Conflicts:
	hmp.c

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

Definitely don't try to unmap a garbage address.
Reported-by: NZuozhi fzz <zuozhi.fzz@alibaba-inc.com>
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Message-id: 1454103689-13042-2-git-send-email-jsnow@redhat.com
(cherry picked from commit 99b4cb71)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Migration of pseries-2.3 doesn't have configuration section. Unfortunately,
QEMU 2.4/2.4.1/2.5 are buggy and always stream and expect the configuration
section, and break migration both ways.

This patch introduces a property which allows to enforce a configuration
section for machines who don't have one.

It can be set at startup:

-machine enforce-config-section=on

or later from the QEMU monitor:

qom-set /machine enforce-config-section on

It is up to the tooling to set or unset this property according to the
version of the QEMU at the other end of the pipe.
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 902c053d)

Conflicts:
	qemu-options.hx

* removed context dependency on 87252e1b
* added to provide 2.5<->2.5.1 migration compat option for
  pseries-2.3 machines
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Commit e1ce0c3c (vl.c: fix regression when reading machine type
from config file) fixed the error message when the machine type
was supplied inside the config file. However now the option name
is not displayed correctly if the error happens when the machine
is specified at command line.

Running
    ./x86_64-softmmu/qemu-system-x86_64 -M q35-1.5 -redir tcp:8022::22
will result in the error message:
    qemu-system-x86_64: -redir tcp:8022::22: unsupported machine type
    Use -machine help to list supported machines

Fixed it by restoring the error location and also extracted the code
dealing with machine options into a separate function.
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <1455303747-19776-2-git-send-email-ehabkost@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
(cherry picked from commit 34f405ae)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

quorum_aio_cb() emits the QUORUM_REPORT_BAD event if there's
an I/O error in a Quorum child. However sacb->aiocb must be
correctly initialized for this to happen. read_quorum_children() and
read_fifo_child() are not doing this, which results in a QEMU crash.
Signed-off-by: NAlberto Garcia <berto@igalia.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Message-id: 8138570d071ba7e25db3736979234a1fd71dbd05.1457610443.git.berto@igalia.com
Signed-off-by: NMax Reitz <mreitz@redhat.com>
(cherry picked from commit b9c600d2)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The v8 ARM ARM defines that unused spaces in the ID_AA64* system
register ranges are Reserved and must RAZ, rather than being UNDEF.
Implement this.

In particular, ARM v8.2 adds a new feature register ID_AA64MMFR2,
and newer versions of the Linux kernel will attempt to read this,
which causes them not to boot up on versions of QEMU missing this fix.

Since the encoding .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 2, .opc2 = 6
is actually defined in ARMv8 (as ID_MMFR4), we give it an entry in
the ARMCPU struct so CPUs can override it, though since none do
this too will just RAZ.

Cc: qemu-stable@nongnu.org
Reported-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1455890863-11203-1-git-send-email-peter.maydell@linaro.org
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Tested-by: NAlex Bennée <alex.bennee@linaro.org>
(cherry picked from commit e20d84c1)

Conflicts:
	target-arm/helper.c

* remove context dep on 4054bfa9Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

vhost currently merges regions with contiguious virtual and physical
addresses.  This breaks for vhost-user since that also needs fds to
match.

Add a vhost_ops entry to compare the fds for vhost-user only.

Cc: qemu-stable@nongnu.org
Cc: Victor Kaplansky <victork@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
(cherry picked from commit ffe42cc1)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

When I reviewed Marc's fw_cfg DMA patches, I completely missed that the
way we set dma_enabled would break migration.

Gerd explained the right way (see reference below): dma_enabled should be
set to true by default, and only true->false transitions should be
possible:

- when the user requests that with

    -global fw_cfg_mem.dma_enabled=off

  or

   -global fw_cfg_io.dma_enabled=off

  as appropriate for the platform,

- when HW_COMPAT_2_4 dictates it,

- when board code initializes fw_cfg without requesting DMA support.

Cc: Marc Marí <markmb@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alexandre DERUMIER <aderumier@odiso.com>
Cc: qemu-stable@nongnu.org
Ref: http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042
Ref: https://bugs.launchpad.net/qemu/+bug/1536487Suggested-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1455823860-22268-1-git-send-email-lersek@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit e6915b5f)

Conflicts:
	include/hw/compat.h

* remove cosmetic dep on c9c0afbbSigned-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Minimizes the possibility to assign
the same bit to different features.
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit fc1769b7)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Commits 1811e64c and a6df8adf use the same virtio feature bit 4
for different features.

Fix it by using different bits.
Reported-by: NLaurent Vivier <lvivier@redhat.com>
Tested-by: NLaurent Vivier <lvivier@redhat.com>
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit 631a4387)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Since QEMU 2.4, we have a configuration section in the migration stream.
This must be skipped for older machines, like it is already done for x86.

This patch fixes the migration of pseries-2.3 from/to QEMU 2.3, but it
breaks migration of the same machine from/to QEMU 2.4/2.4.1/2.5. We do
that anyway because QEMU 2.3 is likely to be more widely deployed than
newer QEMU versions.

Fixes: 61964c23Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 09b5e30d)

Conflicts:
	hw/ppc/spapr.c

*remove dep on 5013c547Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The start_xmit() and e1000_receive_iov() functions implement DMA transfers
iterating over a set of descriptors that the guest's e1000 driver
prepares:

- the TDLEN and RDLEN registers store the total size of the descriptor
  area,

- while the TDH and RDH registers store the offset (in whole tx / rx
  descriptors) into the area where the transfer is supposed to start.

Each time a descriptor is processed, the TDH and RDH register is bumped
(as appropriate for the transfer direction).

QEMU already contains logic to deal with bogus transfers submitted by the
guest:

- Normally, the transmit case wants to increase TDH from its initial value
  to TDT. (TDT is allowed to be numerically smaller than the initial TDH
  value; wrapping at or above TDLEN bytes to zero is normal.) The failsafe
  that QEMU currently has here is a check against reaching the original
  TDH value again -- a complete wraparound, which should never happen.

- In the receive case RDH is increased from its initial value until
  "total_size" bytes have been received; preferably in a single step, or
  in "s->rxbuf_size" byte steps, if the latter is smaller. However, null
  RX descriptors are skipped without receiving data, while RDH is
  incremented just the same. QEMU tries to prevent an infinite loop
  (processing only null RX descriptors) by detecting whether RDH assumes
  its original value during the loop. (Again, wrapping from RDLEN to 0 is
  normal.)

What both directions miss is that the guest could program TDLEN and RDLEN
so low, and the initial TDH and RDH so high, that these registers will
immediately be truncated to zero, and then never reassume their initial
values in the loop -- a full wraparound will never occur.

The condition that expresses this is:

  xdh_start >= s->mac_reg[XDLEN] / sizeof(desc)

i.e., TDH or RDH start out after the last whole rx or tx descriptor that
fits into the TDLEN or RDLEN sized area.

This condition could be checked before we enter the loops, but
pci_dma_read() / pci_dma_write() knows how to fill in buffers safely for
bogus DMA addresses, so we just extend the existing failsafes with the
above condition.

This is CVE-2016-1981.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Prasad Pandit <ppandit@redhat.com>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: qemu-stable@nongnu.org
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1296044Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit dd793a74)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Signed-off-by: NJeff Cody <jcody@redhat.com>
Message-id: 2dbc05efba2f683cb3aaf71aaa9b776ebf7ec57c.1454376655.git.jcody@redhat.com
Reviewed-by: NMax Reitz <mreitz@redhat.com>
[Moved test number from 143 to 144]
Signed-off-by: NMax Reitz <mreitz@redhat.com>

(cherry picked from commit 8983b670)

Conflicts:
	tests/qemu-iotests/group

*removed context dependencies on newer test groups
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This fixes a regression introduced with commit 3f09bfbc.  Multiple
bugs arise in conjunction with live snapshots and mirroring operations
(which include active layer commit).

After a live snapshot occurs, the active layer and the base layer both
have a non-NULL tqe_prev field in the device_list, although the base
node's tqe_prev field points to a NULL entry.  This non-NULL tqe_prev
field occurs after the bdrv_append() in the external snapshot calls
change_parent_backing_link().

In change_parent_backing_link(), when the previous active layer is
removed from device_list, the device_list.tqe_prev pointer is not
set to NULL.

The operating scheme in the block layer is to indicate that a BDS belongs
in the bdrv_states device_list iff the device_list.tqe_prev pointer
is non-NULL.

This patch does two things:

1.) Introduces a new block layer helper bdrv_device_remove() to remove a
    BDS from the device_list, and
2.) uses that new API, which also fixes the regression once used in
    change_parent_backing_link().
Signed-off-by: NJeff Cody <jcody@redhat.com>
Message-id: 0cd51e11c0666c04ddb7c05293fe94afeb551e89.1454376655.git.jcody@redhat.com
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
(cherry picked from commit f8aa905a)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Commit 6c2f9a15 ensured that we would not return NULL when the
caller used an output visitor but had nothing to visit. But
in doing so, it added a FIXME about a reference count leak
that could abort qemu in the (unlikely) case of SIZE_MAX such
visits (more plausible on 32-bit).  (Although that commit
suggested we might fix it in time for 2.5, we ran out of time;
fortunately, it is unlikely enough to bite that it was not
worth worrying about during the 2.5 release.)

This fixes things by documenting the internal contracts, and
explaining why the internal function can return NULL and only
the public facing interface needs to worry about qnull(),
thus avoiding over-referencing the qnull_ global object.

It does not, however, fix the stupidity of the stack mixing
up two separate pieces of information; add a FIXME to explain
that issue, which will be fixed shortly in a future patch.
Signed-off-by: NEric Blake <eblake@redhat.com>
Cc: qemu-stable@nongnu.org
Message-Id: <1454075341-13658-25-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
(cherry picked from commit a8615640)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Jiri saw a hang on pause_all_vcpus called from postcopy_start,
where the cpus are all apparently stopped ('stopped' flag set)
but pause_all_vcpus is still stuck on a cond_wait on qemu_paused_cond.
We suspect this is happening if a qmp_stop is called at about the
same time as the postcopy code calls that pause_all_vcpus;
although they both should have the main lock held, Paolo spotted
the cond_wait unlocks the global lock so perhaps they both
could end up waiting at the same time?
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reported-by: NJiri Denemark <jdenemar@redhat.com>
Message-Id: <1453716498-27238-1-git-send-email-dgilbert@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 96bce683)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

When calculating a pointer to the currently selected fw_cfg item, the
following is used:

  FWCfgEntry *e = &s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];

When s->cur_entry is FW_CFG_INVALID, we are calculating the address of
a non-existent element in s->entries[arch][...], which is undefined.

This patch ensures the resulting entry pointer is set to NULL whenever
s->cur_entry is FW_CFG_INVALID.
Reported-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Message-id: 1446733972-1602-5-git-send-email-somlo@cmu.edu
Cc: Marc Marí <markmb@redhat.com>
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 66f8fd9d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

From the beginning, css support contained an error in csch handling:
instead of setting the clear bit in the function control bits twice, we
need to set the clear pending bit in the activity control bits. Let's
fix this.

Cc: qemu-stable@nongnu.org
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
(cherry picked from commit 4c6bf79a)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

If no event information is pending, the return code
is set to 0x0005 and the length of the response is
set to 8 bytes.
Signed-off-by: NPierre Morel <pmorel@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NSong Shan Gong <gongss@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
(cherry picked from commit f70202be)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

large volume DASD that have > 64k cylinders do claim to have
0xFFFE cylinders as special value in the old 16 bit field. We
want to pass this "token" along to the guest, instead of
calculating the real number. Otherwise qemu might fail with
"cyls must be between 1 and 65535"

Cc: qemu-stable@nongnu.org
Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 972b543c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

After clearing the status register we also have to update the irq line
status.  Otherwise a irq which happends to be pending at reset time
causes a interrupt storm.  And the guest can't stop as the status
register doesn't indicate any pending interrupt.

Both NetBSD and FreeBSD hang on shutdown because of that.

Cc: qemu-stable@nongnu.org
Reported-by: NAndrey Korolyov <andrey@xdel.ru>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1453203884-4125-1-git-send-email-kraxel@redhat.com
(cherry picked from commit 5a866074)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

commit 5be7d9f1
       vhost-net: tell tap backend about the vnet endianness

makes vhost net to set the endianness of the device, but only for
the first device.

In case of multiqueue, we have multiple devices... This patch sets the
endianness for all the devices of the interface.
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit a4076440)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Ne2000 NIC uses ring buffer of NE2000_MEM_SIZE(49152)
bytes to process network packets. Registers PSTART & PSTOP
define ring buffer size & location. Setting these registers
to invalid values could lead to infinite loop or OOB r/w
access issues. Add check to avoid it.
Reported-by: NYang Hongke <yanghongke@huawei.com>
Tested-by: NYang Hongke <yanghongke@huawei.com>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit 415ab35a)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Cc: Jason Wang <jasowang@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit 671f66f8)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit b50c7d45)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

'change' and related operations did not work when used on guest devices
featuring removable media but no actual tray, because
blk_dev_is_tray_open() always returned false for them and the
blockdev-{insert,remove}-medium commands required it to return true.

Fix this by making blockdev-{insert,remove}-medium work on tray-less
devices. Also, blockdev-{open,close}-tray are now explicitly no-ops when
invoked on such devices, and blk_dev_change_media_cb() is instead
called by blockdev-{insert,remove}-medium (for tray-less devices only).
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Message-id: 1454096953-31773-3-git-send-email-mreitz@redhat.com
Reviewed-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 12c7ec87)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Pull out the check whether a block device has a tray from
blk_dev_is_tray_open() into its own function so both attributes (whether
there is a tray vs. whether that tray is open) can be queried
independently.

Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Message-id: 1454096953-31773-2-git-send-email-mreitz@redhat.com
(cherry picked from commit 8f3a73bc)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

While processing transmit(tx) descriptors in 'tx_consume' routine
the switch emulator suffers from an off-by-one error, if a
descriptor was to have more than allowed(ROCKER_TX_FRAGS_MAX=16)
fragments. Fix an incorrect bounds check to avoid it.
Reported-by: NQinghao Tang <luodalongde@gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit 007cd223)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Fix crash when msi=false introduced in 660c97ee (msi_vectors is NULL in
this case)
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
(cherry picked from commit 47213eb1)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
(cherry picked from commit 2c648469)
*context dependency for 47213eb1Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

While processing controller 'CTRL_GET_INFO' command, the routine
'megasas_ctrl_get_info' overflows the '&info' object size. Use its
appropriate size to null initialise it.
Reported-by: NQinghao Tang <luodalongde@gmail.com>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Message-Id: <alpine.LFD.2.20.1512211501420.22471@wniryva>
Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NP J P <ppandit@redhat.com>
(cherry picked from commit 36fef36b)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The aio_context_new() function does not allocate a thread pool. This is
deferred to the first call to the aio_get_thread_pool() accessor. It is
hence forbidden to access the thread_pool field directly, as it may be
NULL. The accessor *must* be used always.

Fixes: ebac1202Reviewed-by: NMichael Tokarev <mjt@tls.msk.ru>
Tested-by: NMichael Tokarev <mjt@tls.msk.ru>
Cc: qemu-stable@nongnu.org
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
(cherry picked from commit 4b3a4f2d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.

This is part of XSA-155.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
(cherry picked from commit 7ea11bf3)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function.  If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.

Fix it by removing the double access to src->nr_segments.

This is part of XSA-155.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
(cherry picked from commit f9e98e5d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Unfortunately the OpenBSD pdksh does not like brackets inside
the right part of a ${variable+word} parameter expansion:

  $ echo "${a+($b)}"
  ksh: ${a+($b)}": bad substitution

though both bash and dash accept them. In any case this line
was causing odd output in the case where nettle is not present:
  nettle    no ()

(because if nettle is not present then $nettle will be "no",
not a null string or unset).

Rewrite it to just use an if.

This bug was originally introduced in becaeb72 and was present
in the 2.4.0 release.

Fixes: https://bugs.launchpad.net/qemu/+bug/1525682
Reported-by: Dmitrij D. Czarkoff
Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1450105357-8516-1-git-send-email-peter.maydell@linaro.org
(cherry picked from commit 18f49881)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

On VSX capable CPUs, the 32 FP registers are mapped to the high-bits
of the 32 first VSX registers. So if you have:

VSR31 = (uint128) 0x0102030405060708090a0b0c0d0e0f00

then

FPR31 = (uint64) 0x0102030405060708

The kernel stores the VSX registers in the fp_state struct following the
host endian element ordering.

On big-endian:

fp_state.fpr[31][0] = 0x0102030405060708
fp_state.fpr[31][1] = 0x090a0b0c0d0e0f00

On little-endian:

fp_state.fpr[31][0] = 0x090a0b0c0d0e0f00
fp_state.fpr[31][1] = 0x0102030405060708

The KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls preserve this ordering, but
QEMU considers it as big-endian and always copies element [0] to the
fpr[] array and element [1] to the vsr[] array. This does not work with
little-endian hosts, and you will get:

(qemu) p $f31
0x90a0b0c0d0e0f00

instead of:

(qemu) p $f31
0x102030405060708

This patch fixes the element ordering for little-endian hosts.
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 3a4b791b)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Vmxnet3 device emulator does not check if the device is active
before activating it, also it did not free the transmit & receive
buffers while deactivating the device, thus resulting in memory
leakage on the host. This patch fixes both these issues to avoid
host memory leakage.
Reported-by: NQinghao Tang <luodalongde@gmail.com>
Reviewed-by: NDmitry Fleytman <dmitry@daynix.com>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: NJason Wang <jasowang@redhat.com>
(cherry picked from commit aa4a3dce)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Make ehci_process_itd return an error in case we didn't do any actual
iso transfer because we've found no active transaction.  That'll avoid
ehci happily run in circles forever if the guest builds a loop out of
idts.

This is CVE-2015-8558.

Cc: qemu-stable@nongnu.org
Reported-by: NQinghao Tang <luodalongde@gmail.com>
Tested-by: NP J P <ppandit@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 156a2e4d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>