aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-08-31vnc: Set default kbd delay to 10msAlexander Graf
The current VNC default keyboard delay is 1ms. With that we're constantly typing faster than the guest receives keyboard events from an XHCI attached USB HID device. The default keyboard delay time in the input layer however is 10ms. I don't know how that number came to be, but empirical tests on some OpenQA driven ARM systems show that 10ms really is a reasonable default number for the delay. This patch moves the VNC delay also to 10ms. That way our default is much safer (good!) and also consistent with the input layer default (also good!). Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1499863425-103133-1-git-send-email-agraf@suse.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit d3b0db6dfea6b3a9ee0d96aceb796bdcafa84314) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31qemu-nbd: Ignore SIGPIPEMax Reitz
qemu proper has done so for 13 years (8a7ddc38a60648257dc0645ab4a05b33d6040063), qemu-img and qemu-io have done so for four years (526eda14a68d5b3596be715505289b541288ef2a). Ignoring this signal is especially important in qemu-nbd because otherwise a client can easily take down the qemu-nbd server by dropping the connection when the server wants to send something, for example: $ qemu-nbd -x foo -f raw -t null-co:// & [1] 12726 $ qemu-io -c quit nbd://localhost/bar can't open device nbd://localhost/bar: No export with name 'bar' available [1] + 12726 broken pipe qemu-nbd -x foo -f raw -t null-co:// In this case, the client sends an NBD_OPT_ABORT and closes the connection (because it is not required to wait for a reply), but the server replies with an NBD_REP_ACK (because it is required to reply). Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20170611123714.31292-1-mreitz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 041e32b8d9d076980b4e35317c0339e57ab888f1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31usb-redir: fix stack overflow in usbredir_log_dataGerd Hoffmann
Don't reinvent a broken wheel, just use the hexdump function we have. Impact: low, broken code doesn't run unless you have debug logging enabled. Reported-by: 李强 <liqiang6-s@360.cn> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20170509110128.27261-1-kraxel@redhat.com (cherry picked from commit bd4a683505b27adc1ac809f71e918e58573d851d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31megasas: do not read SCSI req parameters more than once from framePaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b356807fcdfc45583c437f761fc579ab2a8eab11) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31megasas: do not read command more than once from framePaolo Bonzini
Avoid TOC-TOU bugs by passing the frame_cmd down, and checking cmd->dcmd_opcode instead of cmd->frame->header.frame_cmd. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 36c327a69d723571f02a7691631667cdb1865ee1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31megasas: do not read DCMD opcode more than once from framePaolo Bonzini
Avoid TOC-TOU bugs by storing the DCMD opcode in the MegasasCmd Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 5104fac8539eaf155fc6de93e164be43e1e62242) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31megasas: do not read iovec count more than once from framePaolo Bonzini
Avoid TOC-TOU bugs depending on how the compiler behaves. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 24c0c77af515acbf0f9705e8096f33ef24d37430) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31megasas: do not read sense length more than once from framePaolo Bonzini
Avoid TOC-TOU bugs depending on how the compiler behaves. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 134550bf81a026e18cf58b81e2c2cceaf516f92e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-319pfs: local: forbid client access to metadata (CVE-2017-7493)Greg Kurz
When using the mapped-file security mode, we shouldn't let the client mess with the metadata. The current code already tries to hide the metadata dir from the client by skipping it in local_readdir(). But the client can still access or modify it through several other operations. This can be used to escalate privileges in the guest. Affected backend operations are: - local_mknod() - local_mkdir() - local_open2() - local_symlink() - local_link() - local_unlinkat() - local_renameat() - local_rename() - local_name_to_path() Other operations are safe because they are only passed a fid path, which is computed internally in local_name_to_path(). This patch converts all the functions listed above to fail and return EINVAL when being passed the name of the metadata dir. This may look like a poor choice for errno, but there's no such thing as an illegal path name on Linux and I could not think of anything better. This fixes CVE-2017-7493. Reported-by: Leo Gaspard <leo@gaspard.io> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 7a95434e0ca8a037fd8aa1a2e2461f92585eb77b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31scsi: avoid an off-by-one error in megasas_mmio_writePrasad J Pandit
While reading magic sequence(MFI_SEQ) in megasas_mmio_write, an off-by-one error could occur as 's->adp_reset' index is not reset after reading the last sequence. Reported-by: YY Z <bigbird475958471@gmail.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20170424120634.12268-1-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 24dfa9fa2f90a95ac33c7372de4f4f2c8a2c141f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31audio: release capture buffersGerd Hoffmann
AUD_add_capture() allocates two buffers which are never released. Add the missing calls to AUD_del_capture(). Impact: Allows vnc clients to exhaust host memory by repeatedly starting and stopping audio capture. Fixes: CVE-2017-8309 Cc: P J P <ppandit@redhat.com> Cc: Huawei PSIRT <PSIRT@huawei.com> Reported-by: "Jiangxin (hunter, SCC)" <jiangxin1@huawei.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Message-id: 20170428075612.9997-1-kraxel@redhat.com (cherry picked from commit 3268a845f41253fb55852a8429c32b50f36f349a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31vmw_pvscsi: check message ring page count at initialisationP J P
A guest could set the message ring page count to zero, resulting in infinite loop. Add check to avoid it. Reported-by: YY Z <bigbird475958471@gmail.com> Signed-off-by: P J P <ppandit@redhat.com> Message-Id: <20170425130623.3649-1-ppandit@redhat.com> Reviewed-by: Dmitry Fleytman <dmitry@daynix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit f68826989cd4d1217797251339579c57b3c0934e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" deviceThomas Huth
QEMU currently aborts unexpectedly when the user tries to add and remove a "spapr-tce-table" device: $ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio QEMU 2.9.92 monitor - type 'help' for more information (qemu) device_add spapr-tce-table,id=x (qemu) device_del x ** ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) Aborted (core dumped) The device should not be accessable for the users at all, it's just used internally, so mark it with user_creatable = false. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 1f98e55385d11da1dc0de6440e66f19d191d2a1b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = falseThomas Huth
QEMU currently aborts unexpectedly when a user tries to do something like this: $ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio QEMU 2.9.92 monitor - type 'help' for more information (qemu) device_add spapr-rtc,id=spapr-rtc (qemu) device_del spapr-rtc ** ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) Aborted (core dumped) The RTC device is not meant to be hot-pluggable - it's an internal device only and it even should not be possible to create it a second time with the "-device" parameter, so let's mark this with "user_creatable = false". Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 8ccccff9dd7ba24c7a78861172e8dc6b07f1c392) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatableEduardo Habkost
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit e90f2a8c3e0e677eeea46a9b401c3f98425ffa37) Conflicts: include/hw/qdev-core.h * remove context dep on 08f00df Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31fix qemu-system-unicore32 crashing when calling without -kernelEduardo Otubo
Starting qemu-system-unicore32 without the -kernel parameter results in an assert() returns false and aborts qemu. This patch replaces it with a proper error message followed by exit(1). Signed-off-by: Eduardo Otubo <otubo@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 36bed541ca886da735bef1e8d76d09f8849ed5dd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31hw/s390x/ipl: Fix crash with virtio-scsi-pci deviceThomas Huth
qemu-system-s390x currently crashes when it is started with a virtio-scsi-pci device, e.g.: qemu-system-s390x -nographic -enable-kvm -device virtio-scsi-pci \ -drive file=/tmp/disk.dat,if=none,id=d1,format=raw \ -device scsi-cd,drive=d1,bootindex=1 The problem is that the code in s390_gen_initial_iplb() currently assumes that all SCSI devices are also CCW devices, which is not the case for virtio-scsi-pci of course. Fix it by adding an appropriate check for TYPE_CCW_DEVICE here. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <1493126327-13162-1-git-send-email-thuth@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> (cherry picked from commit 99efaa2696caaf6182958e27d553449674894b27) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31slirp: fix clearing ifq_so from pending packetsSamuel Thibault
The if_fastq and if_batchq contain not only packets, but queues of packets for the same socket. When sofree frees a socket, it thus has to clear ifq_so from all the packets from the queues, not only the first. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1201d308519f1e915866d7583d5136d03cc1d384) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31slirp: tftp, copy sockaddr_sizeMarc-André Lureau
ASAN detects an "unknown-crash" when running pxe-test: /ppc64/pxe/spapr-vlan: ================================================================= ==7143==ERROR: AddressSanitizer: unknown-crash on address 0x7f6dcd298d30 at pc 0x55e22218830d bp 0x7f6dcd2989e0 sp 0x7f6dcd2989d0 READ of size 128 at 0x7f6dcd298d30 thread T2 #0 0x55e22218830c in tftp_session_allocate /home/elmarco/src/qq/slirp/tftp.c:73 #1 0x55e22218a1f8 in tftp_handle_rrq /home/elmarco/src/qq/slirp/tftp.c:289 #2 0x55e22218b54c in tftp_input /home/elmarco/src/qq/slirp/tftp.c:446 #3 0x55e2221833fe in udp6_input /home/elmarco/src/qq/slirp/udp6.c:82 #4 0x55e222137b17 in ip6_input /home/elmarco/src/qq/slirp/ip6_input.c:67 Address 0x7f6dcd298d30 is located in stack of thread T2 at offset 96 in frame #0 0x55e222182420 in udp6_input /home/elmarco/src/qq/slirp/udp6.c:13 This frame has 3 object(s): [32, 48) '<unknown>' [96, 124) 'lhost' <== Memory access at offset 96 partially overflows this variable [160, 200) 'save_ip' <== Memory access at offset 96 partially underflows this variable The sockaddr_storage pointer is the sockaddr_in6 lhost on the stack. Copy only the source addr size. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> (cherry picked from commit 17eb587aeb492fe68f8130b027154ff0921fc0b4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31monitor: Check whether TCG is enabled before running the "info jit" codeThomas Huth
The "info jit" command currently aborts on Mac OS X with the message "qemu_mutex_lock: Invalid argument" when running with "-M accel=qtest". We should only call into the TCG code here if TCG has really been enabled and initialized. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1493179907-22516-1-git-send-email-thuth@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Tested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit b7da97eef74bf834be244de0796ccb01db3985c9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-31target-s390x: Mask the SIGP order_code to 8bit.Philipp Kern
According to "CPU Signaling and Response", "Signal-Processor Orders", the order field is bit position 56-63. Without this, the Linux guest kernel is sometimes unable to stop emulation and enters an infinite loop of "XXX unknown sigp: 0xffffffff00000005". Signed-off-by: Philipp Kern <phil@philkern.de> Reviewed-by: Thomas Huth <thuth@tuxfamily.org> [agraf: add comment according to email] Signed-off-by: Alexander Graf <agraf@suse.de> (cherry picked from commit 601b9a9008c5a612d76073bb3f178621cff41980) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-249pfs: local: fix fchmodat_nofollow() limitationsGreg Kurz
This function has to ensure it doesn't follow a symlink that could be used to escape the virtfs directory. This could be easily achieved if fchmodat() on linux honored the AT_SYMLINK_NOFOLLOW flag as described in POSIX, but it doesn't. There was a tentative to implement a new fchmodat2() syscall with the correct semantics: https://patchwork.kernel.org/patch/9596301/ but it didn't gain much momentum. Also it was suggested to look at an O_PATH based solution in the first place. The current implementation covers most use-cases, but it notably fails if: - the target path has access rights equal to 0000 (openat() returns EPERM), => once you've done chmod(0000) on a file, you can never chmod() again - the target path is UNIX domain socket (openat() returns ENXIO) => bind() of UNIX domain sockets fails if the file is on 9pfs The solution is to use O_PATH: openat() now succeeds in both cases, and we can ensure the path isn't a symlink with fstat(). The associated entry in "/proc/self/fd" can hence be safely passed to the regular chmod() syscall. The previous behavior is kept for older systems that don't have O_PATH. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Zhi Yong Wu <zhiyong.wu@ucloud.cn> Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org> (cherry picked from commit 4751fd5328dfcd4fe2f9055728a72a0e3ae56512) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24block/nfs: fix mutex assertion in nfs_file_close()Jeff Cody
Commit c096358e747e88fc7364e40e3c354ee0bb683960 introduced assertion checks for when qemu_mutex() functions are called without the corresponding qemu_mutex_init() having initialized the mutex. This uncovered a latent bug in qemu's nfs driver - in nfs_client_close(), the NFSClient structure is overwritten with zeros, prior to the mutex being destroyed. Go ahead and destroy the mutex in nfs_client_close(), and change where we call qemu_mutex_init() so that it is correctly balanced. There are also a couple of memory leaks obscured by the memset, so this fixes those as well. Finally, we should be able to get rid of the memset(), as it isn't necessary. Cc: qemu-stable@nongnu.org Signed-off-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 113fe792fd4931dd0538f03859278b8719ee4fa2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24hw/i386: allow SHPC for Q35 machineAleksandr Bezzubikov
Unmask previously masked SHPC feature in _OSC method. Signed-off-by: Aleksandr Bezzubikov <zuban32s@gmail.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a41c78c135eb1850826e96b2154690323ff66719) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24cpu: don't allow negative core idLaurent Vivier
With pseries machine type a negative core-id is not managed properly: -1 gives an inaccurate error message ("core -1 already populated"), -2 crashes QEMU (core dump) As it seems a negative value is invalid for any architecture, instead of checking this in spapr_core_pre_plug() I think it's better to check this in the generic part, core_prop_set_core_id() Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20170802103259.25940-1-lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit be2960baae07e5257cde8c814cbd91647e235147) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24block: Skip implicit nodes in query-block/blockstatsKevin Wolf
Commits 0db832f and 6cdbceb introduced the automatic insertion of filter nodes above the top layer of mirror and commit block jobs. The assumption made there was that since libvirt doesn't do node-level management of the block layer yet, it shouldn't be affected by added nodes. This is true as far as commands issued by libvirt are concerned. It only uses BlockBackend names to address nodes, so any operations it performs still operate on the root of the tree as intended. However, the assumption breaks down when you consider query commands, which return data for the wrong node now. These commands also return information on some child nodes (bs->file and/or bs->backing), which libvirt does make use of, and which refer to the wrong nodes, too. One of the consequences is that oVirt gets wrong information about the image size and stops the VM in response as long as a mirror or commit job is running: https://bugzilla.redhat.com/show_bug.cgi?id=1470634 This patch fixes the problem by hiding the implicit nodes created automatically by the mirror and commit block jobs in the output of query-block and BlockBackend-based query-blockstats as long as the user doesn't indicate that they are aware of those nodes by providing a node name for them in the QMP command to start the block job. The node-based commands query-named-block-nodes and query-blockstats with query-nodes=true still show all nodes, including implicit ones. This ensures that users that are capable of node-level management can still access the full information; users that only know BlockBackends won't use these commands. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> (cherry picked from commit d3c8c67469ee70fcae116d5abc277a7ebc8a19fd) Conflicts: block/qapi.c include/block/block_int.h * fix context deps on 46eade7b and 5a9347c6 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24qemu-iotests: Test automatic commit job cancel on hot unplugKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> (cherry picked from commit c3971b883a596abc6af45f53d2f43fb2f59ccd3b) *prereq for d3c8c674 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24input: Decrement queue count on kbd delayAlexander Graf
Delays in the input layer are special cased input events. Every input event is accounted for in a global intput queue count. The special cased delays however did not get removed from the queue, leading to queue overruns and thus silent key drops after typing quite a few characters. Signed-off-by: Alexander Graf <agraf@suse.de> Message-id: 1498117318-162102-1-git-send-email-agraf@suse.de Fixes: be1a7176 ("input: add support for kbd delays") Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 77b0359bf414ad666d1714dc9888f1017c08e283) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24input: limit kbd queue depthGerd Hoffmann
Apply a limit to the number of items we accept into the keyboard queue. Impact: Without this limit vnc clients can exhaust host memory by sending keyboard events faster than qemu feeds them to the guest. Fixes: CVE-2017-8379 Cc: P J P <ppandit@redhat.com> Cc: Huawei PSIRT <PSIRT@huawei.com> Reported-by: jiangxin1@huawei.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20170428084237.23960-1-kraxel@redhat.com (cherry picked from commit fa18f36a461984eae50ab957e47ec78dae3c14fc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24virtio-net: fix offload ctrl endianJason Wang
Spec said offloads should be le64, so use virtio_ldq_p() to guarantee valid endian. Fixes: 644c98587d4c ("virtio-net: dynamic network offloads configuration") Cc: qemu-stable@nongnu.org Cc: Dmitry Fleytman <dfleytma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 189ae6bb5ce1f5a322f8691d00fe942ba43dd601) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24spapr: fix memory leak in spapr_core_pre_plug()Greg Kurz
In case of error, we must ensure the dynamically allocated base_core_type is freed, like it is done everywhere else in this function. This is a regression introduced in QEMU 2.9 by commit 8149e2992f78. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit df8658de43db242ea82183d75cc957c2b0fa013a) Conflicts: hw/ppc/spapr.c * fix context dep on 459264ef2 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24commit: Add NULL check for overlay_bsKevin Wolf
I can't see how overlay_bs could become NULL with the current code, but other code in this function already checks it and we can make Coverity happy with this check, so let's add it. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit b1e1fa0c3afc7f671fbc24645bdf67949a5657e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24virtio-scsi: finalize IOMMU supportJason Wang
After converting to use DMA api for virtio devices, we should use dma_as instead of address_space_memory. Otherwise it won't work if IOMMU is enabled. Fixes: commit 8607f5c3072c ("virtio: convert to use DMA api") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <1499170866-9068-1-git-send-email-jasowang@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 025bdeab3c163aee9604a60b2332a5fcbcc00f8d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24spapr: fix migration to pseries machine < 2.8Laurent Vivier
since commit 5c4537bd ("spapr: Fix 2.7<->2.8 migration of PCI host bridge"), some migration fields are forged from the new ones in spapr_pci_pre_save(). It works well, except when the number of MSI devices is 0, because in this case the function exits immediately. This fix moves the migration code before the exit code. The problem can be reproduced with these commands: source qemu-2.9: qemu-system-ppc64 -monitor stdio -M pseries-2.6 -nodefaults -S destination qemu-2.6: qemu-system-ppc64 -monitor stdio -M pseries-2.6 -nodefaults \ -incoming tcp:0:4444 on the source: migrate tcp:localhost:4444 Destination fails with the following error: qemu-system-ppc64: error while loading state for instance 0x0 of device 'spapr_pci' qemu-system-ppc64: load of migration failed: Invalid argument Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit e806b4db1477a1c6bfda7bba28c7f26c47f18e1e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24hid: Reset kbd modifiers on resetAlexander Graf
When resetting the keyboard, we need to reset not just the pending keystrokes, but also any pending modifiers. Otherwise there's a race when we're getting reset while running an escape sequence (modifier 0x100). Cc: qemu-stable@nongnu.org Signed-off-by: Alexander Graf <agraf@suse.de> Message-id: 1498117295-162030-1-git-send-email-agraf@suse.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 51dbea77a29ea46173373a6dad4ebd95d4661f42) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-249pfs: local: remove: use correct path componentBruce Rogers
Commit a0e640a8 introduced a path processing error. Pass fstatat the dirpath based path component instead of the entire path. Signed-off-by: Bruce Rogers <brogers@suse.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 790db7efdbe1536acf1c4f4f95a0316dbda59433) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24block: Do not strcmp() with NULL uri->schemeMax Reitz
uri_parse(...)->scheme may be NULL. In fact, probably every field may be NULL, and the callers do test this for all of the other fields but not for scheme (except for block/gluster.c; block/vxhs.c does not access that field at all). We can easily fix this by using g_strcmp0() instead of strcmp(). Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20170613205726.13544-1-mreitz@redhat.com Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit f69165a8feca055cf4a37d13ab0fc5beec3cb372) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24nbd: fix NBD over TLSPaolo Bonzini
When attaching the NBD QIOChannel to an AioContext, the TLS channel should be used, not the underlying socket channel. This is because, trivially, the TLS channel will be the one that we read/write to and thus the one that will get the qio_channel_yield() call. Fixes: ff82911cd3f69f028f2537825c9720ff78bc3f19 Cc: qemu-stable@nongnu.org Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Tested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 96d06835dc40007673cdfab6322e9042c4077113) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24blkverify: Catch bs->exact_filename overflowMax Reitz
The bs->exact_filename field may not be sufficient to store the full blkverify node filename. In this case, we should not generate a filename at all instead of an unusable one. Cc: qemu-stable@nongnu.org Reported-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20170613172006.19685-3-mreitz@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 05cc758a3dfc79488d0a8eb7f5830a41871e78d0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24blkdebug: Catch bs->exact_filename overflowMax Reitz
The bs->exact_filename field may not be sufficient to store the full blkdebug node filename. In this case, we should not generate a filename at all instead of an unusable one. Cc: qemu-stable@nongnu.org Reported-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20170613172006.19685-2-mreitz@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit de81d72d3d13a19edf4d461be3b0f5a877be0234) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24commit: Fix completion with extra referenceKevin Wolf
commit_complete() can't assume that after its block_job_completed() the job is actually immediately freed; someone else may still be holding references. In this case, the op blockers on the intermediate nodes make the graph reconfiguration in the completion code fail. Call block_job_remove_all_bdrv() manually so that we know for sure that any blockers on intermediate nodes are given up. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 4f78a16fee462471416dc49b409d57b2071cf3d9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24nbd: Fix regression on resiliency to port scanEric Blake
Back in qemu 2.5, qemu-nbd was immune to port probes (a transient server would not quit, regardless of how many probe connections came and went, until a connection actually negotiated). But we broke that in commit ee7d7aa when removing the return value to nbd_client_new(), although that patch also introduced a bug causing an assertion failure on a client that fails negotiation. We then made it worse during refactoring in commit 1a6245a (a segfault before we could even assert); the (masked) assertion was cleaned up in d3780c2 (still in 2.6), and just recently we finally fixed the segfault ("nbd: Fully intialize client in case of failed negotiation"). But that still means that ever since we added TLS support to qemu-nbd, we have been vulnerable to an ill-timed port-scan being able to cause a denial of service by taking down qemu-nbd before a real client has a chance to connect. Since negotiation is now handled asynchronously via coroutines, we no longer have a synchronous point of return by re-adding a return value to nbd_client_new(). So this patch instead wires things up to pass the negotiation status through the close_fn callback function. Simple test across two terminals: $ qemu-nbd -f raw -p 30001 file $ nmap 127.0.0.1 -p 30001 && \ qemu-io -c 'r 0 512' -f raw nbd://localhost:30001 Note that this patch does not change what constitutes successful negotiation (thus, a client must enter transmission phase before that client can be considered as a reason to terminate the server when the connection ends). Perhaps we may want to tweak things in a later patch to also treat a client that uses NBD_OPT_ABORT as being a 'successful' negotiation (the client correctly talked the NBD protocol, and informed us it was not going to use our export after all), but that's a discussion for another day. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1451614 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20170608222617.20376-1-eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0c9390d978cbf61e8f16c9f580fa96b305c43568) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24nbd: Fully initialize client in case of failed negotiationEric Blake
If a non-NBD client connects to qemu-nbd, we would end up with a SIGSEGV in nbd_client_put() because we were trying to unregister the client's association to the export, even though we skipped inserting the client into that list. Easy trigger in two terminals: $ qemu-nbd -p 30001 --format=raw file $ nmap 127.0.0.1 -p 30001 nmap claims that it thinks it connected to a pago-services1 server (which probably means nmap could be updated to learn the NBD protocol and give a more accurate diagnosis of the open port - but that's not our problem), then terminates immediately, so our call to nbd_negotiate() fails. The fix is to reorder nbd_co_client_start() to ensure that all initialization occurs before we ever try talking to a client in nbd_negotiate(), so that the teardown sequence on negotiation failure doesn't fault while dereferencing a half-initialized object. While debugging this, I also noticed that nbd_update_server_watch() called by nbd_client_closed() was still adding a channel to accept the next client, even when the state was no longer RUNNING. That is fixed by making nbd_can_accept() pay attention to the current state. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1451614 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20170527030421.28366-1-eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit df8ad9f128c15aa0a0ebc7b24e9a22c9775b67af) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24commit: Fix use after free in completionKevin Wolf
The final bdrv_set_backing_hd() could be working on already freed nodes because the commit job drops its references (through BlockBackends) to both overlay_bs and top already a bit earlier. One way to trigger the bug is hot unplugging a disk for which blockdev_mark_auto_del() cancels the block job. Fix this by taking BDS-level references while we're still using the nodes. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> (cherry picked from commit 19ebd13ed45ad5d5f277f5914d55b83f13eb09eb) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24target/xtensa: handle unknown registers in gdbstubMax Filippov
Xtensa cores may have registers of types/sizes not supported by the gdbstub accessors. Ignore writes to such registers and return zero on read, but always return correct register size, so that gdb on the other side is able to access all registers in the packet holding unsupported registers in the middle. This fixes gdb interaction with cores that have vector/custom TIE registers. Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit dd7b952b793e341c905355581a21cdbaa8b13c31) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24spapr: fix memory leak in spapr_memory_pre_plug()Greg Kurz
The string returned by object_property_get_str() is dynamically allocated. (Spotted by Coverity, CID 1375942) Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 8a9e0e7b890b2598da94646bf6a7272f3d3924de) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24spapr: add pre_plug function for memoryLaurent Vivier
This allows to manage errors before the memory has started to be hotplugged. We already have the function for the CPU cores. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> [dwg: Fixed a couple of style nits] Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit c871bc70bb22d1d70451bc813ecb008fe98cc92b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24target/ppc: fix memory leak in kvmppc_is_mem_backend_page_size_ok()Greg Kurz
The string returned by object_property_get_str() is dynamically allocated. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 2d3e302ec2246d703ffa8d8f8769a3fa448d8145) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-24target/ppc: pass const string to kvmppc_is_mem_backend_page_size_ok()Greg Kurz
This function has three implementations. Two are stubs that do nothing and the third one only passes the obj_path argument to: Object *object_resolve_path(const char *path, bool *ambiguous); Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit ec69355beffe138c0f97306e65410e5dbc605554) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-08-03pc: Use "min-[x]level" on compat_propsEduardo Habkost
Since the automatic cpuid-level code was introduced in commit c39c0edf9bb3b968ba95484465a50c7b19f4aa3a ("target-i386: Automatically set level/xlevel/xlevel2 when needed"), the CPU model tables just define the default CPUID level code (set using "min-level"). Setting "[x]level" forces CPUID level to a specific value and disable the automatic-level logic. But the PC compat code was not updated and the existing "[x]level" compat properties broke compatibility for people using features that triggered the auto-level code. To keep previous behavior, we should set "min-[x]level" instead of "[x]level" on compat_props. This was not a problem for most cases, because old machine-types don't have full-cpuid-auto-level enabled. The only common use case it broke was the CPUID[7] auto-level code, that was already enabled since the first CPUID[7] feature was introduced (in QEMU 1.4.0). This causes the regression reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1454641 Change the PC compat code to use "min-[x]level" instead of "[x]level" on compat_props, and add new test cases to ensure we don't break this again. Reported-by: "Guo, Zhiyi" <zhguo@redhat.com> Fixes: c39c0edf9bb ("target-i386: Automatically set level/xlevel/xlevel2 when needed") Cc: qemu-stable@nongnu.org Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 1f43571604da85c62f25f3ba6d275b1b5ea76ca2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-23 02:35:41 +0000