aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-08-27hw/riscv: Allow 64 bit access to SiFive CLINTAlistair Francis
Commit 5d971f9e672507210e77d020d89e0e89165c8fc9 "memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"" broke most RISC-V boards as they do 64 bit accesses to the CLINT and QEMU would trigger a fault. Fix this failure by allowing 8 byte accesses. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei<zhiwei_liu@c-sky.com> Message-Id: <122b78825b077e4dfd39b444d3a46fe894a7804c.1593547870.git.alistair.francis@wdc.com> (cherry picked from commit 70b78d4e71494c90d2ccb40381336bc9b9a22f79) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-27memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"Michael S. Tsirkin
Memory API documentation documents valid .min_access_size and .max_access_size fields and explains that any access outside these boundaries is blocked. This is what devices seem to assume. However this is not what the implementation does: it simply ignores the boundaries unless there's an "accepts" callback. Naturally, this breaks a bunch of devices. Revert to the documented behaviour. Devices that want to allow any access can just drop the valid field, or add the impl field to have accesses converted to appropriate length. Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <rth@twiddle.net> Fixes: CVE-2020-13754 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1842363 Fixes: a014ed07bd5a ("memory: accept mismatching sizes in memory_region_access_valid") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200610134731.1514409-1-mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 5d971f9e672507210e77d020d89e0e89165c8fc9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-27libqos: pci-pc: use 32-bit write for EJ registerPaolo Bonzini
The memory region ops have min_access_size == 4 so obey it. Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4b7c06837ae0b1ff56473202a42e7e386f53d6db) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-27libqos: usb-hcd-ehci: use 32-bit write for config registerPaolo Bonzini
The memory region ops have min_access_size == 4 so obey it. Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 89ed83d8b23c11d250c290593cad3ca839d5b053) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-25linux-user/strace.list: fix epoll_create{,1} -strace outputSergei Trofimovich
Fix syscall name and parameters priinter. Before the change: ``` $ alpha-linux-user/qemu-alpha -strace -L /usr/alpha-unknown-linux-gnu/ /tmp/a ... 1274697 %s(%d)(2097152,274903156744,274903156760,274905840712,274877908880,274903235616) = 3 1274697 exit_group(0) ``` After the change: ``` $ alpha-linux-user/qemu-alpha -strace -L /usr/alpha-unknown-linux-gnu/ /tmp/a ... 1273719 epoll_create1(2097152) = 3 1273719 exit_group(0) ``` Fixes: 9cbc0578cb6 ("Improve output of various syscalls") Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> CC: Riku Voipio <riku.voipio@iki.fi> CC: Laurent Vivier <laurent@vivier.eu> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200416175957.1274882-1-slyfox@gentoo.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit fd568660b7ae9b9e45cbb616acc91ae4c065c32d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-25aio-posix: disable fdmon-io_uring when GSource is usedStefan Hajnoczi
The glib event loop does not call fdmon_io_uring_wait() so fd handlers waiting to be submitted build up in the list. There is no benefit is using io_uring when the glib GSource is being used, so disable it instead of implementing a more complex fix. This fixes a memory leak where AioHandlers would build up and increasing amounts of CPU time were spent iterating them in aio_pending(). The symptom is that guests become slow when QEMU is built with io_uring support. Buglink: https://bugs.launchpad.net/qemu/+bug/1877716 Fixes: 73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf ("aio-posix: add io_uring fd monitoring implementation") Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Oleksandr Natalenko <oleksandr@redhat.com> Message-id: 20200511183630.279750-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit ba607ca8bff4d2c2062902f8355657c865ac7c29) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-25aio-posix: don't duplicate fd handler deletion in fdmon_io_uring_destroy()Stefan Hajnoczi
The io_uring file descriptor monitoring implementation has an internal list of fd handlers that are pending submission to io_uring. fdmon_io_uring_destroy() deletes all fd handlers on the list. Don't delete fd handlers directly in fdmon_io_uring_destroy() for two reasons: 1. This duplicates the aio-posix.c AioHandler deletion code and could become outdated if the struct changes. 2. Only handlers with the FDMON_IO_URING_REMOVE flag set are safe to remove. If the flag is not set then something still has a pointer to the fd handler. Let aio-posix.c and its user worry about that. In practice this isn't an issue because fdmon_io_uring_destroy() is only called when shutting down so all users have removed their fd handlers, but the next patch will need this! Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Oleksandr Natalenko <oleksandr@redhat.com> Message-id: 20200511183630.279750-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit de137e44f75d9868f5b548638081850f6ac771f2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-25KVM: x86: believe what KVM says about WAITPKGPaolo Bonzini
Currently, QEMU is overriding KVM_GET_SUPPORTED_CPUID's answer for the WAITPKG bit depending on the "-overcommit cpu-pm" setting. This is a bad idea because it does not even check if the host supports it, but it can be done in x86_cpu_realizefn just like we do for the MONITOR bit. This patch moves it there, while making it conditional on host support for the related UMWAIT MSR. Cc: qemu-stable@nongnu.org Reported-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit e1e43813e7908b063938a3d01f172f88f6190c80) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24net: use peer when purging queue in qemu_flush_or_purge_queue_packets()Jason Wang
The sender of packet will be checked in the qemu_net_queue_purge() but we use NetClientState not its peer when trying to purge the incoming queue in qemu_flush_or_purge_packets(). This will trigger the assert in virtio_net_reset since we can't pass the sender check: hw/net/virtio-net.c:533: void virtio_net_reset(VirtIODevice *): Assertion `!virtio_net_get_subqueue(nc)->async_tx.elem' failed. #9 0x55a33fa31b78 in virtio_net_reset hw/net/virtio-net.c:533:13 #10 0x55a33fc88412 in virtio_reset hw/virtio/virtio.c:1919:9 #11 0x55a341d82764 in virtio_bus_reset hw/virtio/virtio-bus.c:95:9 #12 0x55a341dba2de in virtio_pci_reset hw/virtio/virtio-pci.c:1824:5 #13 0x55a341db3e02 in virtio_pci_common_write hw/virtio/virtio-pci.c:1252:13 #14 0x55a33f62117b in memory_region_write_accessor memory.c:496:5 #15 0x55a33f6205e4 in access_with_adjusted_size memory.c:557:18 #16 0x55a33f61e177 in memory_region_dispatch_write memory.c:1488:16 Reproducer: https://www.mail-archive.com/qemu-devel@nongnu.org/msg701914.html Fix by using the peer. Reported-by: "Alexander Bulekov" <alxndr@bu.edu> Acked-by: Alexander Bulekov <alxndr@bu.edu> Fixes: ca77d85e1dbf9 ("net: complete all queued packets on VM stop") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 5fe19fb81839ea42b592b409f725349cf3c73551) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24virtiofsd: stay below fs.file-max sysctl value (CVE-2020-10717)Stefan Hajnoczi
The system-wide fs.file-max sysctl value determines how many files can be open. It defaults to a value calculated based on the machine's RAM size. Previously virtiofsd would try to set RLIMIT_NOFILE to 1,000,000 and this allowed the FUSE client to exhaust the number of open files system-wide on Linux hosts with less than 10 GB of RAM! Take fs.file-max into account when choosing the default RLIMIT_NOFILE value. Fixes: CVE-2020-10717 Reported-by: Yuval Avrahami <yavrahami@paloaltonetworks.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200501140644.220940-3-stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 8c1d353d107b4fc344e27f2f08ea7fa25de2eea2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24virtiofsd: add --rlimit-nofile=NUM optionStefan Hajnoczi
Make it possible to specify the RLIMIT_NOFILE on the command-line. Users running multiple virtiofsd processes should allocate a certain number to each process so that the system-wide limit can never be exhausted. When this option is set to 0 the rlimit is left at its current value. This is useful when a management tool wants to configure the rlimit itself. The default behavior remains unchanged: try to set the limit to 1,000,000 file descriptors if the current rlimit is lower. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200501140644.220940-2-stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 6dbb716877728ce4eb51619885ef6ef4ada9565f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24iotests/283: Use consistent size for source and targetKevin Wolf
The test case forgot to specify the null-co size for the target node. When adding a check to backup that both sizes match, this would fail because of the size mismatch and not the behaviour that the test really wanted to test. Fixes: a541fcc27c98b96da187c7d4573f3270f3ddd283 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200430142755.315494-2-kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 813cc2545b82409fd504509f0ba2e96fab6edb9e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24Fix tulip breakageHelge Deller
The tulip network driver in a qemu-system-hppa emulation is broken in the sense that bigger network packages aren't received any longer and thus even running e.g. "apt update" inside the VM fails. The breakage was introduced by commit 8ffb7265af ("check frame size and r/w data length") which added checks to prevent accesses outside of the rx/tx buffers. But the new checks were implemented wrong. The variable rx_frame_len counts backwards, from rx_frame_size down to zero, and the variable len is never bigger than rx_frame_len, so accesses just can't happen and the checks are unnecessary. On the contrary the checks now prevented bigger packages to be moved into the rx buffers. This patch reverts the wrong checks and were sucessfully tested with a qemu-system-hppa emulation. Fixes: 8ffb7265af ("check frame size and r/w data length") Buglink: https://bugs.launchpad.net/bugs/1874539 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit d9b69640391618045949f7c500b87fc129f862ed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24es1370: check total frame count against current framePrasad J Pandit
A guest user may set channel frame count via es1370_write() such that, in es1370_transfer_audio(), total frame count 'size' is lesser than the number of frames that are processed 'cnt'. int cnt = d->frame_cnt >> 16; int size = d->frame_cnt & 0xffff; if (size < cnt), it results in incorrect calculations leading to OOB access issue(s). Add check to avoid it. Reported-by: Ren Ding <rding@gatech.edu> Reported-by: Hanqing Zhao <hanqing@gatech.edu> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-id: 20200514200608.1744203-1-ppandit@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 369ff955a8497988d079c4e3fa1e93c2570c1c69) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24ati-vga: check mm_index before recursive call (CVE-2020-13800)Prasad J Pandit
While accessing VGA registers via ati_mm_read/write routines, a guest may set 's->regs.mm_index' such that it leads to infinite recursion. Check mm_index value to avoid such recursion. Log an error message for wrong values. Reported-by: Ren Ding <rding@gatech.edu> Reported-by: Hanqing Zhao <hanqing@gatech.edu> Reported-by: Yi Ren <c4tren@gmail.com> Message-id: 20200604090830.33885-1-ppandit@redhat.com Suggested-by: BALATON Zoltan <balaton@eik.bme.hu> Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit a98610c429d52db0937c1e48659428929835c455) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24xen/9pfs: yield when there isn't enough room on the ringStefano Stabellini
Instead of truncating replies, which is problematic, wait until the client reads more data and frees bytes on the reply ring. Do that by calling qemu_coroutine_yield(). The corresponding qemu_coroutine_enter_if_inactive() is called from xen_9pfs_bh upon receiving the next notification from the client. We need to be careful to avoid races in case xen_9pfs_bh and the coroutine are both active at the same time. In xen_9pfs_bh, wait until either the critical section is over (ring->co == NULL) or until the coroutine becomes inactive (qemu_coroutine_yield() was called) before continuing. Then, simply wake up the coroutine if it is inactive. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200521192627.15259-2-sstabellini@kernel.org> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit a4c4d462729466c4756bac8a0a8d77eb63b21ef7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24Revert "9p: init_in_iov_from_pdu can truncate the size"Stefano Stabellini
This reverts commit 16724a173049ac29c7b5ade741da93a0f46edff7. It causes https://bugs.launchpad.net/bugs/1877688. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200521192627.15259-1-sstabellini@kernel.org> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit cf45183b718f02b1369e18c795dc51bc1821245d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24xen-9pfs: Fix log messages of reply errorsChristian Schoenebeck
If delivery of some 9pfs response fails for some reason, log the error message by mentioning the 9P protocol reply type, not by client's request type. The latter could be misleading that the error occurred already when handling the request input. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Message-Id: <ad0e5a9b6abde52502aa40b30661d29aebe1590a.1589132512.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 9bbb7e0fe081efff2e41f8517c256b72a284fe9b) *prereq for cf45183b718 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-249pfs: include linux/limits.h for XATTR_SIZE_MAXDan Robertson
linux/limits.h should be included for the XATTR_SIZE_MAX definition used by v9fs_xattrcreate. Fixes: 3b79ef2cf488 ("9pfs: limit xattr size in xattrcreate") Signed-off-by: Dan Robertson <dan@dlrobertson.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200515203015.7090-2-dan@dlrobertson.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 03556ea920b23c466ce7c1283199033de33ee671) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-249pfs: local: ignore O_NOATIME if we don't have permissionsOmar Sandoval
QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view, it believes it has permissions to use O_NOATIME (e.g., a process running as root in the virtual machine). Additionally, overlayfs on Linux opens files on the lower layer using O_NOATIME, so in this case a 9pfs mount can't be used as a lower layer for overlayfs (cf. https://github.com/osandov/drgn/blob/dabfe1971951701da13863dbe6d8a1d172ad9650/vmtest/onoatimehack.c and https://github.com/NixOS/nixpkgs/issues/54509). Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g., network filesystems. open(2) notes that O_NOATIME "may not be effective on all filesystems. One example is NFS, where the server maintains the access time." This means that we can honor it when possible but fall back to ignoring it. Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Omar Sandoval <osandov@fb.com> Message-Id: <e9bee604e8df528584693a4ec474ded6295ce8ad.1587149256.git.osandov@fb.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit a5804fcf7b22fc7d1f9ec794dd284c7d504bd16b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24block: Call attention to truncation of long NBD exportsEric Blake
Commit 93676c88 relaxed our NBD client code to request export names up to the NBD protocol maximum of 4096 bytes without NUL terminator, even though the block layer can't store anything longer than 4096 bytes including NUL terminator for display to the user. Since this means there are some export names where we have to truncate things, we can at least try to make the truncation a bit more obvious for the user. Note that in spite of the truncated display name, we can still communicate with an NBD server using such a long export name; this was deemed nicer than refusing to even connect to such a server (since the server may not be under our control, and since determining our actual length limits gets tricky when nbd://host:port/export and nbd+unix:///export?socket=/path are themselves variable-length expansions beyond the export name but count towards the block layer name length). Reported-by: Xueqiang Wei <xuwei@redhat.com> Fixes: https://bugzilla.redhat.com/1843684 Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200610163741.3745251-3-eblake@redhat.com> (cherry picked from commit 5c86bdf1208916ece0b87e1151c9b48ee54faa3e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24virtio-balloon: unref the iothread when unrealizingDavid Hildenbrand
We took a reference when realizing, so let's drop that reference when unrealizing. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-4-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 105aef9c9479786d27c1c45c9b0b1fa03dc46be3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24virtio-balloon: fix free page hinting check on unrealizeDavid Hildenbrand
Checking against guest features is wrong. We allocated data structures based on host features. We can rely on "free_page_bh" as an indicator whether to un-do stuff instead. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-3-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 49b01711b8eb3796c6904c7f85d2431572cfe54f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24virtio-balloon: fix free page hinting without an iothreadDavid Hildenbrand
In case we don't have an iothread, we mark the feature as abscent but still add the queue. 'free_page_bh' remains set to NULL. qemu-system-i386 \ -M microvm \ -nographic \ -device virtio-balloon-device,free-page-hint=true \ -nographic \ -display none \ -monitor none \ -serial none \ -qtest stdio Doing a "write 0xc0000e30 0x24 0x030000000300000003000000030000000300000003000000030000000300000003000000" We will trigger a SEGFAULT. Let's move the check and bail out. While at it, move the static initializations to instance_init(). free_page_report_status and block_iothread are implicitly set to the right values (0/false) already, so drop the initialization. Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Reported-by: Alexander Bulekov <alxndr@bu.edu> Cc: qemu-stable@nongnu.org Cc: Wei Wang <wei.w.wang@intel.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200520100439.19872-2-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 12fc8903a8ee09fb5f642de82699a0b211e1b5a7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24nbd/server: Avoid long error message assertions CVE-2020-10761Eric Blake
Ever since commit 36683283 (v2.8), the server code asserts that error strings sent to the client are well-formed per the protocol by not exceeding the maximum string length of 4096. At the time the server first started sending error messages, the assertion could not be triggered, because messages were completely under our control. However, over the years, we have added latent scenarios where a client could trigger the server to attempt an error message that would include the client's information if it passed other checks first: - requesting NBD_OPT_INFO/GO on an export name that is not present (commit 0cfae925 in v2.12 echoes the name) - requesting NBD_OPT_LIST/SET_META_CONTEXT on an export name that is not present (commit e7b1948d in v2.12 echoes the name) At the time, those were still safe because we flagged names larger than 256 bytes with a different message; but that changed in commit 93676c88 (v4.2) when we raised the name limit to 4096 to match the NBD string limit. (That commit also failed to change the magic number 4096 in nbd_negotiate_send_rep_err to the just-introduced named constant.) So with that commit, long client names appended to server text can now trigger the assertion, and thus be used as a denial of service attack against a server. As a mitigating factor, if the server requires TLS, the client cannot trigger the problematic paths unless it first supplies TLS credentials, and such trusted clients are less likely to try to intentionally crash the server. We may later want to further sanitize the user-supplied strings we place into our error messages, such as scrubbing out control characters, but that is less important to the CVE fix, so it can be a later patch to the new nbd_sanitize_name. Consideration was given to changing the assertion in nbd_negotiate_send_rep_verr to instead merely log a server error and truncate the message, to avoid leaving a latent path that could trigger a future CVE DoS on any new error message. However, this merely complicates the code for something that is already (correctly) flagging coding errors, and now that we are aware of the long message pitfall, we are less likely to introduce such errors in the future, which would make such error handling dead code. Reported-by: Xueqiang Wei <xuwei@redhat.com> CC: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com/1843684 CVE-2020-10761 Fixes: 93676c88d7 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200610163741.3745251-2-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> (cherry picked from commit 5c4fe018c025740fef4a0a4421e8162db0c3eefd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24net: Do not include a newline in the id of -nic devicesThomas Huth
The '\n' sneaked in by accident here, an "id" string should really not contain a newline character at the end. Fixes: 78cd6f7bf6b ('net: Add a new convenience option "--nic" ...') Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200518074352.23125-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 0561dfac082becdd9e89110249a27b309b62aa9f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-249p: Lock directory streams with a CoMutexGreg Kurz
Locking was introduced in QEMU 2.7 to address the deprecation of readdir_r(3) in glibc 2.24. It turns out that the frontend code is the worst place to handle a critical section with a pthread mutex: the code runs in a coroutine on behalf of the QEMU mainloop and then yields control, waiting for the fsdev backend to process the request in a worker thread. If the client resends another readdir request for the same fid before the previous one finally unlocked the mutex, we're deadlocked. This never bit us because the linux client serializes readdir requests for the same fid, but it is quite easy to demonstrate with a custom client. A good solution could be to narrow the critical section in the worker thread code and to return a copy of the dirent to the frontend, but this causes quite some changes in both 9p.c and codir.c. So, instead of that, in order for people to easily backport the fix to older QEMU versions, let's simply use a CoMutex since all the users for this sit in coroutines. Fixes: 7cde47d4a89d ("9p: add locking to V9fsDir") Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158981894794.109297.3530035833368944254.stgit@bahia.lan> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit ed463454efd0ac3042ff772bfe1b1d846dc281a5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24qemu-nbd: Close inherited stderrRaphael Pour
Close inherited stderr of the parent if fork_process is false. Otherwise no one will close it. (introduced by e6df58a5) This only affected 'qemu-nbd -c /dev/nbd0'. Signed-off-by: Raphael Pour <raphael.pour@hetzner.com> Message-Id: <d8ddc993-9816-836e-a3de-c6edab9d9c49@hetzner.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: Enhance commit message] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 0eaf453ebf6788885fbb5d40426b154ef8805407) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24target/arm: Clear tail in gvec_fmul_idx_*, gvec_fmla_idx_*Richard Henderson
Must clear the tail for AdvSIMD when SVE is enabled. Fixes: ca40a6e6e39 Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200513163245.17915-15-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 525d9b6d42844e187211d25b69be8b378785bc24) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-08-24hostmem: don't use mbind() if host-nodes is emptyIgor Mammedov
Since 5.0 QEMU uses hostmem backend for allocating main guest RAM. The backend however calls mbind() which is typically NOP in case of default policy/absent host-nodes bitmap. However when runing in container with black-listed mbind() syscall, QEMU fails to start with error "cannot bind memory to host NUMA nodes: Operation not permitted" even when user hasn't provided host-nodes to pin to explictly (which is the case with -m option) To fix issue, call mbind() only in case when user has provided host-nodes explicitly (i.e. host_nodes bitmap is not empty). That should allow to run QEMU in containers with black-listed mbind() without memory pinning. If QEMU provided memory-pinning is required user still has to white-list mbind() in container configuration. Reported-by: Manuel Hohmann <mhohmann@physnet.uni-hamburg.de> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200430154606.6421-1-imammedo@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 70b6d525dfb51d5e523d568d1139fc051bc223c5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-04-28Update version for v5.0.0 releasev5.0.0Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-22Update version for v5.0.0-rc4 releasev5.0.0-rc4Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-22target/arm: Fix ID_MMFR4 value on AArch64 'max' CPUPeter Maydell
In commit 41a4bf1feab098da4cd the added code to set the CNP field in ID_MMFR4 for the AArch64 'max' CPU had a typo where it used the wrong variable name, resulting in ID_MMFR4 fields AC2, XNX and LSM being wrong. Fix the typo. Fixes: 41a4bf1feab098da4cd Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com> Message-id: 20200422124501.28015-1-peter.maydell@linaro.org
2020-04-21slirp: update to fix CVE-2020-1983Marc-André Lureau
This is an update on the stable-4.2 branch of libslirp.git: git shortlog 55ab21c9a3..2faae0f778f81 Marc-André Lureau (1): Fix use-afte-free in ip_reass() (CVE-2020-1983) CVE-2020-1983 is actually a follow up fix for commit 126c04acbabd7ad32c2b018fe10dfac2a3bc1210 ("Fix heap overflow in ip_reass on big packet input") which was was included in qemu v4.1 (commit e1a4a24d262ba5ac74ea1795adb3ab1cd574c7fb "slirp: update with CVE-2019-14378 fix"). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200421170227.843555-1-marcandre.lureau@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-20target/ppc: Fix TCG temporary leaks in gen_slbia()Philippe Mathieu-Daudé
This fixes: $ qemu-system-ppc64 \ -machine pseries-4.1 -cpu power9 \ -smp 4 -m 12G -accel tcg ... ... Quiescing Open Firmware ... Booting Linux via __start() @ 0x0000000002000000 ... Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries Opcode 1f 12 0f 00 (7ce003e4) leaked temporaries [*] https://www.mail-archive.com/qemu-discuss@nongnu.org/msg05400.html Fixes: 0418bf78fe8 ("Fix ISA v3.0 (POWER9) slbia implementation") Reported-by: Dennis Clarke <dclarke@blastwave.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20200417090749.14310-1-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-20Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200417' ↵Peter Maydell
into staging ppc patch queue for 2020-04-17 Here are a few late bugfixes for qemu-5.0 in the ppc target code. Unless some really nasty last minute bug shows up, I expect this to be the last ppc pull request for qemu-5.0. # gpg: Signature made Fri 17 Apr 2020 06:02:13 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-5.0-20200417: target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts target/ppc: Fix wrong interpretation of the disposition flag. linux-user/ppc: Fix padding in mcontext_t for ppc64 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-20Merge remote-tracking branch ↵Peter Maydell
'remotes/vivier2/tags/linux-user-for-5.0-pull-request' into staging Fix epoll_create1() for qemu-alpha # gpg: Signature made Thu 16 Apr 2020 16:28:15 BST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/linux-user-for-5.0-pull-request: linux-user/syscall.c: add target-to-host mapping for epoll_create1() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-20block/iscsi:fix heap-buffer-overflow in iscsi_aio_ioctl_cbChen Qun
There is an overflow, the source 'datain.data[2]' is 100 bytes, but the 'ss' is 252 bytes.This may cause a security issue because we can access a lot of unrelated memory data. The len for sbp copy data should take the minimum of mx_sb_len and sb_len_wr, not the maximum. If we use iscsi device for VM backend storage, ASAN show stack: READ of size 252 at 0xfffd149dcfc4 thread T0 #0 0xaaad433d0d34 in __asan_memcpy (aarch64-softmmu/qemu-system-aarch64+0x2cb0d34) #1 0xaaad45f9d6d0 in iscsi_aio_ioctl_cb /qemu/block/iscsi.c:996:9 #2 0xfffd1af0e2dc (/usr/lib64/iscsi/libiscsi.so.8+0xe2dc) #3 0xfffd1af0d174 (/usr/lib64/iscsi/libiscsi.so.8+0xd174) #4 0xfffd1af19fac (/usr/lib64/iscsi/libiscsi.so.8+0x19fac) #5 0xaaad45f9acc8 in iscsi_process_read /qemu/block/iscsi.c:403:5 #6 0xaaad4623733c in aio_dispatch_handler /qemu/util/aio-posix.c:467:9 #7 0xaaad4622f350 in aio_dispatch_handlers /qemu/util/aio-posix.c:510:20 #8 0xaaad4622f350 in aio_dispatch /qemu/util/aio-posix.c:520 #9 0xaaad46215944 in aio_ctx_dispatch /qemu/util/async.c:298:5 #10 0xfffd1bed12f4 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f4) #11 0xaaad46227de0 in glib_pollfds_poll /qemu/util/main-loop.c:219:9 #12 0xaaad46227de0 in os_host_main_loop_wait /qemu/util/main-loop.c:242 #13 0xaaad46227de0 in main_loop_wait /qemu/util/main-loop.c:518 #14 0xaaad43d9d60c in qemu_main_loop /qemu/softmmu/vl.c:1662:9 #15 0xaaad4607a5b0 in main /qemu/softmmu/main.c:49:5 #16 0xfffd1a460b9c in __libc_start_main (/lib64/libc.so.6+0x20b9c) #17 0xaaad43320740 in _start (aarch64-softmmu/qemu-system-aarch64+0x2c00740) 0xfffd149dcfc4 is located 0 bytes to the right of 100-byte region [0xfffd149dcf60,0xfffd149dcfc4) allocated by thread T0 here: #0 0xaaad433d1e70 in __interceptor_malloc (aarch64-softmmu/qemu-system-aarch64+0x2cb1e70) #1 0xfffd1af0e254 (/usr/lib64/iscsi/libiscsi.so.8+0xe254) #2 0xfffd1af0d174 (/usr/lib64/iscsi/libiscsi.so.8+0xd174) #3 0xfffd1af19fac (/usr/lib64/iscsi/libiscsi.so.8+0x19fac) #4 0xaaad45f9acc8 in iscsi_process_read /qemu/block/iscsi.c:403:5 #5 0xaaad4623733c in aio_dispatch_handler /qemu/util/aio-posix.c:467:9 #6 0xaaad4622f350 in aio_dispatch_handlers /qemu/util/aio-posix.c:510:20 #7 0xaaad4622f350 in aio_dispatch /qemu/util/aio-posix.c:520 #8 0xaaad46215944 in aio_ctx_dispatch /qemu/util/async.c:298:5 #9 0xfffd1bed12f4 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f4) #10 0xaaad46227de0 in glib_pollfds_poll /qemu/util/main-loop.c:219:9 #11 0xaaad46227de0 in os_host_main_loop_wait /qemu/util/main-loop.c:242 #12 0xaaad46227de0 in main_loop_wait /qemu/util/main-loop.c:518 #13 0xaaad43d9d60c in qemu_main_loop /qemu/softmmu/vl.c:1662:9 #14 0xaaad4607a5b0 in main /qemu/softmmu/main.c:49:5 #15 0xfffd1a460b9c in __libc_start_main (/lib64/libc.so.6+0x20b9c) #16 0xaaad43320740 in _start (aarch64-softmmu/qemu-system-aarch64+0x2c00740) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200418062602.10776-1-kuhn.chenqun@huawei.com Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-17target/ppc: Fix mtmsr(d) L=1 variant that loses interruptsNicholas Piggin
If mtmsr L=1 sets MSR[EE] while there is a maskable exception pending, it does not cause an interrupt. This causes the test case to hang: https://lists.gnu.org/archive/html/qemu-ppc/2019-10/msg00826.html More recently, Linux reduced the occurance of operations (e.g., rfi) which stop translation and allow pending interrupts to be processed. This started causing hangs in Linux boot in long-running kernel tests, running with '-d int' shows the decrementer stops firing despite DEC wrapping and MSR[EE]=1. https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208301.html The cause is the broken mtmsr L=1 behaviour, which is contrary to the architecture. From Power ISA v3.0B, p.977, Move To Machine State Register, Programming Note states: If MSR[EE]=0 and an External, Decrementer, or Performance Monitor exception is pending, executing an mtmsrd instruction that sets MSR[EE] to 1 will cause the interrupt to occur before the next instruction is executed, if no higher priority exception exists Fix this by handling L=1 exactly the same way as L=0, modulo the MSR bits altered. The confusion arises from L=0 being "context synchronizing" whereas L=1 is "execution synchronizing", which is a weaker semantic. However this is not a relaxation of the requirement that these exceptions cause interrupts when MSR[EE]=1 (e.g., when mtmsr executes to completion as TCG is doing here), rather it specifies how a pipelined processor can have multiple instructions in flight where one may influence how another behaves. Cc: qemu-stable@nongnu.org Reported-by: Anton Blanchard <anton@ozlabs.org> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200414111131.465560-1-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-04-17target/ppc: Fix wrong interpretation of the disposition flag.Ganesh Goudar
Bitwise AND with kvm_run->flags to evaluate if we recovered from MCE or not is not correct, As disposition in kvm_run->flags is a two-bit integer value and not a bit map, So check for equality instead of bitwise AND. Without the fix qemu treats any unrecoverable mce error as recoverable and ends up in a mce loop inside the guest, Below are the MCE logs before and after the fix. Before fix: [ 66.775757] MCE: CPU0: Initiator CPU [ 66.775891] MCE: CPU0: Unknown [ 66.776587] MCE: CPU0: machine check (Harmless) Host UE Indeterminate [Recovered] [ 66.776857] MCE: CPU0: NIP: [c0080000000e00b8] mcetest_tlbie+0xb0/0x128 [mcetest_tlbie] After fix: [ 20.650577] CPU: 0 PID: 1415 Comm: insmod Tainted: G M O 5.6.0-fwnmi-arv+ #11 [ 20.650618] NIP: c0080000023a00e8 LR: c0080000023a00d8 CTR: c000000000021fe0 [ 20.650660] REGS: c0000001fffd3d70 TRAP: 0200 Tainted: G M O (5.6.0-fwnmi-arv+) [ 20.650708] MSR: 8000000002a0b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 42000222 XER: 20040000 [ 20.650758] CFAR: c00000000000b940 DAR: c0080000025e00e0 DSISR: 00000200 IRQMASK: 0 [ 20.650758] GPR00: c0080000023a00d8 c0000001fddd79a0 c0080000023a8500 0000000000000039 [ 20.650758] GPR04: 0000000000000001 0000000000000000 0000000000000000 0000000000000007 [ 20.650758] GPR08: 0000000000000007 c0080000025e00e0 0000000000000000 00000000000000f7 [ 20.650758] GPR12: 0000000000000000 c000000001900000 c00000000101f398 c0080000025c052f [ 20.650758] GPR16: 00000000000003a8 c0080000025c0000 c0000001fddd7d70 c0000000015b7940 [ 20.650758] GPR20: 000000000000fff1 c000000000f72c28 c0080000025a0988 0000000000000000 [ 20.650758] GPR24: 0000000000000100 c0080000023a05d0 c0000000001f1d70 0000000000000000 [ 20.650758] GPR28: c0000001fde20000 c0000001fd02b2e0 c0080000023a0000 c0080000025e0000 [ 20.651178] NIP [c0080000023a00e8] mcetest_tlbie+0xe8/0xf0 [mcetest_tlbie] [ 20.651220] LR [c0080000023a00d8] mcetest_tlbie+0xd8/0xf0 [mcetest_tlbie] [ 20.651262] Call Trace: [ 20.651280] [c0000001fddd79a0] [c0080000023a00d8] mcetest_tlbie+0xd8/0xf0 [mcetest_tlbie] (unreliable) [ 20.651340] [c0000001fddd7a10] [c00000000001091c] do_one_initcall+0x6c/0x2c0 [ 20.651390] [c0000001fddd7af0] [c0000000001f7998] do_init_module+0x90/0x298 [ 20.651433] [c0000001fddd7b80] [c0000000001f61a8] load_module+0x1f58/0x27a0 [ 20.651476] [c0000001fddd7d40] [c0000000001f6c70] __do_sys_finit_module+0xe0/0x100 [ 20.651526] [c0000001fddd7e20] [c00000000000b9d0] system_call+0x5c/0x68 [ 20.651567] Instruction dump: [ 20.651594] e8410018 3c620000 e8638020 480000cd e8410018 3c620000 e8638028 480000bd [ 20.651646] e8410018 7be904e4 39400000 612900e0 <7d434a64> 4bffff74 3c4c0001 38428410 [ 20.651699] ---[ end trace 4c40897f016b4340 ]--- [ 20.653310] Bus error [ 20.655575] MCE: CPU0: machine check (Harmless) Host UE Indeterminate [Not recovered] [ 20.655575] MCE: CPU0: NIP: [c0080000023a00e8] mcetest_tlbie+0xe8/0xf0 [mcetest_tlbie] [ 20.655576] MCE: CPU0: Initiator CPU [ 20.655576] MCE: CPU0: Unknown Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200408170944.16003-1-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-04-17linux-user/ppc: Fix padding in mcontext_t for ppc64Richard Henderson
The padding that was added in 95cda4c44ee was added to a union, and so it had no effect. This fixes misalignment errors detected by clang sanitizers for ppc64 and ppc64le. In addition, only ppc64 allocates space for VSX registers, so do not save them for ppc32. The kernel only has references to CONFIG_SPE in signal_32.c, so do not attempt to save them for ppc64. Fixes: 95cda4c44ee Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200407032105.26711-1-richard.henderson@linaro.org> Acked-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-04-16linux-user/syscall.c: add target-to-host mapping for epoll_create1()Sergei Trofimovich
Noticed by Barnabás Virágh as a python-3.7 failue on qemu-alpha. The bug shows up on alpha as it's one of the targets where EPOLL_CLOEXEC differs from other targets: sysdeps/unix/sysv/linux/alpha/bits/epoll.h: EPOLL_CLOEXEC = 01000000 sysdeps/unix/sysv/linux/bits/epoll.h: EPOLL_CLOEXEC = 02000000 Bug: https://bugs.gentoo.org/717548 Reported-by: Barnabás Virágh Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> CC: Riku Voipio <riku.voipio@iki.fi> CC: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200415220508.5044-1-slyfox@gentoo.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-04-15Update version for v5.0.0-rc3 releasev5.0.0-rc3Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-15vhost-user-gpu: Release memory returned by vu_queue_pop() with free()Philippe Mathieu-Daudé
vu_queue_pop() returns memory that must be freed with free(). Cc: qemu-stable@nongnu.org Reported-by: Coverity (CID 1421887 ALLOC_FREE_MISMATCH) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-15Merge remote-tracking branch 'remotes/mdroth/tags/qga-pull-2020-04-15-tag' ↵Peter Maydell
into staging qemu-ga patch queue for hard-freeze * enforce 48MB limit for guest-file-read to avoid memory allocation failures # gpg: Signature made Wed 15 Apr 2020 15:23:48 BST # gpg: using RSA key CEACC9E15534EBABB82D3FA03353C9CEF108B584 # gpg: issuer "mdroth@linux.vnet.ibm.com" # gpg: Good signature from "Michael Roth <flukshun@gmail.com>" [full] # gpg: aka "Michael Roth <mdroth@utexas.edu>" [full] # gpg: aka "Michael Roth <mdroth@linux.vnet.ibm.com>" [full] # Primary key fingerprint: CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584 * remotes/mdroth/tags/qga-pull-2020-04-15-tag: qga: Restrict guest-file-read count to 48 MB to avoid crashes qga: Extract qmp_guest_file_read() to common commands.c qga: Extract guest_file_handle_find() to commands-common.h Revert "prevent crash when executing guest-file-read with large count" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-15qga: Restrict guest-file-read count to 48 MB to avoid crashesPhilippe Mathieu-Daudé
On [*] Daniel Berrangé commented: The QEMU guest agent protocol is not sensible way to access huge files inside the guest. It requires the inefficient process of reading the entire data into memory than duplicating it again in base64 format, and then copying it again in the JSON serializer / monitor code. For arbitrary general purpose file access, especially for large files, use a real file transfer program or use a network block device, not the QEMU guest agent. To avoid bug reports as BZ#1594054 (CVE-2018-12617), follow his suggestion to put a low, hard limit on "count" in the guest agent QAPI schema, and don't allow count to be larger than 48 MB. [*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg693176.html Fixes: CVE-2018-12617 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1594054 Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> *update schema documentation to indicate 48MB limit instead of 10MB Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-04-15qga: Extract qmp_guest_file_read() to common commands.cPhilippe Mathieu-Daudé
Extract the common code shared by both POSIX/Win32 implementations. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-04-15qga: Extract guest_file_handle_find() to commands-common.hPhilippe Mathieu-Daudé
As we are going to reuse this method, declare it in common header. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-04-15Revert "prevent crash when executing guest-file-read with large count"Philippe Mathieu-Daudé
As noted by Daniel Berrangé in [*], the fix from commit 807e2b6fce which replaced malloc() by try_malloc() is not enough, the process can still run out of memory a few line later: 346 buf = g_try_malloc0(count + 1); 347 if (!buf) { 348 error_setg(errp, 349 "failed to allocate sufficient memory " 350 "to complete the requested service"); 351 return NULL; 352 } 353 is_ok = ReadFile(fh, buf, count, &read_count, NULL); 354 if (!is_ok) { 355 error_setg_win32(errp, GetLastError(), "failed to read file"); 356 slog("guest-file-read failed, handle %" PRId64, handle); 357 } else { 358 buf[read_count] = 0; 359 read_data = g_new0(GuestFileRead, 1); ^^^^^^ Instead we are going to put a low hard limit on 'count' in the next commits. This reverts commit 807e2b6fce022707418bc8f61c069d91c613b3d2. [*] https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg03471.html Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2020-04-15Merge remote-tracking branch 'remotes/stsquad/tags/pull-more-fixes-150420-1' ↵Peter Maydell
into staging More small fixes for rc3 - tweak docker FEATURE flags for document building - include sphinx configure check in config.log - disable PIE for Windows builds - fix /proc/self/stat handling - a number of gdbstub fixups following GByteArray conversion # gpg: Signature made Wed 15 Apr 2020 11:38:56 BST # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-more-fixes-150420-1: gdbstub: Introduce gdb_get_float32() to get 32-bit float registers gdbstub: Do not use memset() on GByteArray gdbstub: i386: Fix gdb_get_reg16() parameter to unbreak gdb target/m68k/helper: Fix m68k_fpu_gdb_get_reg() use of GByteArray linux-user: fix /proc/self/stat handling configure: disable PIE for Windows builds configure: redirect sphinx-build check to config.log tests/docker: add docs FEATURE flag and use for test-misc Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-14 08:07:34 +0000