aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-28Update version for 6.0.1 releasev6.0.1stable-6.0Michael Roth1-1/+1
Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-27Partially revert "build: -no-pie is no functional linker flag"Jessica Clarke1-1/+4
This partially reverts commit bbd2d5a8120771ec59b86a80a1f51884e0a26e53. This commit was misguided and broke using --disable-pie on any distro that enables PIE by default in their compiler driver, including Debian and its derivatives. Whilst -no-pie is not a linker flag, it is a compiler driver flag that ensures -pie is not automatically passed by it to the linker. Without it, all compile_prog checks will fail as any code built with the explicit -fno-pie will fail to link with the implicit default -pie due to trying to use position-dependent relocations. The only bug that needed fixing was LDFLAGS_NOPIE being used as a flag for the linker itself in pc-bios/optionrom/Makefile. Note this does not reinstate exporting LDFLAGS_NOPIE, as it is unused, since the only previous use was the one that should not have existed. I have also updated the comment for the -fno-pie and -no-pie checks to reflect what they're actually needed for. Fixes: bbd2d5a8120771ec59b86a80a1f51884e0a26e53 Cc: Christian Ehrhardt <christian.ehrhardt@canonical.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-27hw/display/artist: Fix bug in coordinate extraction in artist_vram_read() ↵Helge Deller1-4/+4
and artist_vram_write() The CDE desktop on HP-UX 10 shows wrongly rendered pixels when the local screen menu is closed. This bug was introduced by commit c7050f3f167b ("hw/display/artist: Refactor x/y coordination extraction") which converted the coordinate extraction in artist_vram_read() and artist_vram_write() to use the ADDR_TO_X and ADDR_TO_Y macros, but forgot to right-shift the address by 2 as it was done before. Signed-off-by: Helge Deller <deller@gmx.de> Fixes: c7050f3f167b ("hw/display/artist: Refactor x/y coordination extraction") Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Sven Schnelle <svens@stackframe.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <YK1aPb8keur9W7h2@ls3530> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 01f750f5fef1afd8f6abc0548910f87d473e26d5) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-27libvhost-user: fix VHOST_USER_REM_MEM_REG skipping mmap_addrDavid Hildenbrand1-0/+1
We end up not copying the mmap_addr of all existing regions, resulting in a SEGFAULT once we actually try to map/access anything within our memory regions. Fixes: 875b9fd97b34 ("Support individual region unmap in libvhost-user") Cc: qemu-stable@nongnu.org Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Raphael Norwitz <raphael.norwitz@nutanix.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Coiby Xu <coiby.xu@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20211011201047.62587-1-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 6889eb2d431ae962e3e083b57bff47cd573cb1c4) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-27vhost-user: fix duplicated notifier MR initXueming Li1-2/+3
In case of device resume after suspend, VQ notifier MR still valid. Duplicated registrations explode memory block list and slow down device resume. Fixes: 44866521bd6e ("vhost-user: support registering external host notifiers") Cc: tiwei.bie@intel.com Cc: qemu-stable@nongnu.org Cc: Yuwei Zhang <zhangyuwei.9149@bytedance.com> Signed-off-by: Xueming Li <xuemingl@nvidia.com> Message-Id: <20211008080215.590292-1-xuemingl@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a1ed9ef1de87c3e86ff68589604298ec90875a14) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17pvrdma: Fix the ring init error flow (CVE-2021-3608)Marcel Apfelbaum1-1/+1
Do not unmap uninitialized dma addresses. Fixes: CVE-2021-3608 Reviewed-by: VictorV (Kunlun Lab) <vv474172261@gmail.com> Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <20210630115246.2178219-1-marcel@redhat.com> Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> (cherry picked from commit 66ae37d8cc313f89272e711174a846a229bcdbd3) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17pvrdma: Ensure correct input on ring init (CVE-2021-3607)Marcel Apfelbaum1-0/+5
Check the guest passed a non zero page count for pvrdma device ring buffers. Fixes: CVE-2021-3607 Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com> Reviewed-by: VictorV (Kunlun Lab) <vv474172261@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <20210630114634.2168872-1-marcel@redhat.com> Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> (cherry picked from commit 32e5703cfea07c91e6e84bcb0313f633bb146534) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17hw/rdma: Fix possible mremap overflow in the pvrdma device (CVE-2021-3582)Marcel Apfelbaum1-0/+7
Ensure mremap boundaries not trusting the guest kernel to pass the correct buffer length. Fixes: CVE-2021-3582 Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com> Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <20210616110600.20889-1-marcel.apfelbaum@gmail.com> Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> (cherry picked from commit 284f191b4abad213aed04cb0458e1600fd18d7c4) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset' (CVE-2021-3546)Li Qiang1-0/+4
If 'virgl_cmd_get_capset' set 'max_size' to 0, the 'virgl_renderer_fill_caps' will write the data after the 'resp'. This patch avoid this by checking the returned 'max_size'. virtio-gpu fix: abd7f08b23 ("display: virtio-gpu-3d: check virgl capabilities max_size") Fixes: CVE-2021-3546 Reported-by: Li Qiang <liq3ea@163.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-8-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 9f22893adcb02580aee5968f32baa2cd109b3ec2) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing' ↵Li Qiang1-1/+4
(CVE-2021-3544) If 'virgl_renderer_resource_attach_iov' failed, the 'res_iovs' will be leaked. Fixes: CVE-2021-3544 Reported-by: Li Qiang <liq3ea@163.com> virtio-gpu fix: 33243031da ("virtio-gpu-3d: fix memory leak in resource attach backing") Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-7-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 63736af5a6571d9def93769431e0d7e38c6677bf) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref' (CVE-2021-3544)Li Qiang1-0/+7
The 'res->iov' will be leaked if the guest trigger following sequences: virgl_cmd_create_resource_2d virgl_resource_attach_backing virgl_cmd_resource_unref This patch fixes this. Fixes: CVE-2021-3544 Reported-by: Li Qiang <liq3ea@163.com> virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak in virgl_cmd_resource_unref" Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-6-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit f6091d86ba9ea05f4e111b9b42ee0005c37a6779) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix memory leak while calling 'vg_resource_unref' ↵Li Qiang1-0/+1
(CVE-2021-3544) If the guest trigger following sequences, the attach_backing will be leaked: vg_resource_create_2d vg_resource_attach_backing vg_resource_unref This patch fix this by freeing 'res->iov' in vg_resource_destroy. Fixes: CVE-2021-3544 Reported-by: Li Qiang <liq3ea@163.com> virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak in virgl_cmd_resource_unref") Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-5-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit b7afebcf9e6ecf3cf9b5a9b9b731ed04bca6aa3e) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix memory leak in vg_resource_attach_backing (CVE-2021-3544)Li Qiang1-0/+5
Check whether the 'res' has already been attach_backing to avoid memory leak. Fixes: CVE-2021-3544 Reported-by: Li Qiang <liq3ea@163.com> virtio-gpu fix: 204f01b309 ("virtio-gpu: fix memory leak in resource attach backing") Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-4-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit b9f79858a614d95f5de875d0ca31096eaab72c3b) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix resource leak in 'vg_resource_create_2d' (CVE-2021-3544)Li Qiang1-0/+1
Call 'vugbm_buffer_destroy' in error path to avoid resource leak. Fixes: CVE-2021-3544 Reported-by: Li Qiang <liq3ea@163.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-3-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 86dd8fac2acc366930a5dc08d3fb1b1e816f4e1e) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info ↵Li Qiang1-0/+1
(CVE-2021-3545) Otherwise some of the 'resp' will be leaked to guest. Fixes: CVE-2021-3545 Reported-by: Li Qiang <liq3ea@163.com> virtio-gpu fix: 42a8dadc74 ("virtio-gpu: fix information leak in getting capset info dispatch") Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210516030403.107723-2-liq3ea@163.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 121841b25d72d13f8cad554363138c360f1250ea) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17usb: limit combined packets to 1 MiB (CVE-2021-3527)Gerd Hoffmann1-1/+3
usb-host and usb-redirect try to batch bulk transfers by combining many small usb packets into a single, large transfer request, to reduce the overhead and improve performance. This patch adds a size limit of 1 MiB for those combined packets to restrict the host resources the guest can bind that way. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20210503132915.2335822-6-kraxel@redhat.com> (cherry picked from commit 05a40b172e4d691371534828078be47e7fff524c) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17usb/redir: avoid dynamic stack allocation (CVE-2021-3527)Gerd Hoffmann1-3/+3
Use autofree heap allocation instead. Fixes: 4f4321c11ff ("usb: use iovecs in USBPacket") Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210503132915.2335822-3-kraxel@redhat.com> (cherry picked from commit 7ec54f9eb62b5d177e30eb8b1cad795a5f8d8986) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-17uas: add stream number sanity checks.Gerd Hoffmann1-0/+11
The device uses the guest-supplied stream number unchecked, which can lead to guest-triggered out-of-band access to the UASDevice->data3 and UASDevice->status3 fields. Add the missing checks. Fixes: CVE-2021-3713 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reported-by: Chen Zhe <chenzhe@huawei.com> Reported-by: Tan Jingguo <tanjingguo@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210818120505.1258262-2-kraxel@redhat.com> (cherry picked from commit 13b250b12ad3c59114a6a17d59caf073ce45b33a) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-15virtio-mem-pci: Fix memory leak when creating MEMORY_DEVICE_SIZE_CHANGE eventDavid Hildenbrand1-6/+1
Apparently, we don't have to duplicate the string. Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size changes") Cc: qemu-stable@nongnu.org Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210929162445.64060-2-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 75b98cb9f6456ccf194211beffcbf93b0a995fa4) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-15hmp: Unbreak "change vnc"Markus Armbruster1-1/+1
HMP command "change vnc" can take the password as argument, or prompt for it: (qemu) change vnc password 123 (qemu) change vnc password Password: *** (qemu) This regressed in commit cfb5387a1d "hmp: remove "change vnc TARGET" command", v6.0.0. (qemu) change vnc passwd 123 Password: *** (qemu) change vnc passwd (qemu) The latter passes NULL to qmp_change_vnc_password(), which is a no-no. Looks like it puts the display into "password required, but none set" state. The logic error is easy to miss in review, but testing should've caught it. Fix the obvious way. Fixes: cfb5387a1de2acda23fb5c97d2378b9e7ddf8025 Cc: qemu-stable@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20210909081219.308065-2-armbru@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 6193344f9337f8b76cd44ce94a32c9900d907d35) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-15qemu-nbd: Change default cache mode to writebackNir Soffer2-4/+8
Both qemu and qemu-img use writeback cache mode by default, which is already documented in qemu(1). qemu-nbd uses writethrough cache mode by default, and the default cache mode is not documented. According to the qemu-nbd(8): --cache=CACHE The cache mode to be used with the file. See the documentation of the emulator's -drive cache=... option for allowed values. qemu(1) says: The default mode is cache=writeback. So users have no reason to assume that qemu-nbd is using writethough cache mode. The only hint is the painfully slow writing when using the defaults. Looking in git history, it seems that qemu used writethrough in the past to support broken guests that did not flush data properly, or could not flush due to limitations in qemu. But qemu-nbd clients can use NBD_CMD_FLUSH to flush data, so using writethrough does not help anyone. Change the default cache mode to writback, and document the default and available values properly in the online help and manual. With this change converting image via qemu-nbd is 3.5 times faster. $ qemu-img create dst.img 50g $ qemu-nbd -t -f raw -k /tmp/nbd.sock dst.img Before this change: $ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock" Benchmark #1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock Time (mean ± σ): 83.639 s ± 5.970 s [User: 2.733 s, System: 6.112 s] Range (min … max): 76.749 s … 87.245 s 3 runs After this change: $ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock" Benchmark #1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock Time (mean ± σ): 23.522 s ± 0.433 s [User: 2.083 s, System: 5.475 s] Range (min … max): 23.234 s … 24.019 s 3 runs Users can avoid the issue by using --cache=writeback[1] but the defaults should give good performance for the common use case. [1] https://bugzilla.redhat.com/1990656 Signed-off-by: Nir Soffer <nsoffer@redhat.com> Message-Id: <20210813205519.50518-1-nsoffer@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 09615257058a0ae87b837bb041f56f7312d9ead8) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-15virtio-net: fix use after unmap/free for sgJason Wang1-7/+32
When mergeable buffer is enabled, we try to set the num_buffers after the virtqueue elem has been unmapped. This will lead several issues, E.g a use after free when the descriptor has an address which belongs to the non direct access region. In this case we use bounce buffer that is allocated during address_space_map() and freed during address_space_unmap(). Fixing this by storing the elems temporarily in an array and delay the unmap after we set the the num_buffers. This addresses CVE-2021-3748. Reported-by: Alexander Bulekov <alxndr@bu.edu> Fixes: fbe78f4f55c6 ("virtio-net support") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit bedd7e93d01961fcb16a97ae45d93acf357e11f6) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-15target/arm: Don't skip M-profile reset entirely in user modePeter Maydell1-0/+19
Currently all of the M-profile specific code in arm_cpu_reset() is inside a !defined(CONFIG_USER_ONLY) ifdef block. This is unintentional: it happened because originally the only M-profile-specific handling was the setup of the initial SP and PC from the vector table, which is system-emulation only. But then we added a lot of other M-profile setup to the same "if (ARM_FEATURE_M)" code block without noticing that it was all inside a not-user-mode ifdef. This has generally been harmless, but with the addition of v8.1M low-overhead-loop support we ran into a problem: the reset of FPSCR.LTPSIZE to 4 was only being done for system emulation mode, so if a user-mode guest tried to execute the LE instruction it would incorrectly take a UsageFault. Adjust the ifdefs so only the really system-emulation specific parts are covered. Because this means we now run some reset code that sets up initial values in the FPCCR and similar FPU related registers, explicitly set up the registers controlling FPU context handling in user-emulation mode so that the FPU works by design and not by chance. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/613 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210914120725.24992-2-peter.maydell@linaro.org (cherry picked from commit b62ceeaf8096fdbbbfdc6087da0028bc4a4dd77e) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14audio: Never send migration sectionDr. David Alan Gilbert1-0/+10
The audio migration vmstate is empty, and always has been; we can't just remove it though because an old qemu might send it us. Changes with -audiodev now mean it's sometimes created when it didn't used to be, and can confuse migration to old qemu. Change it so that vmstate_audio is never sent; if it's received it should still be accepted, and old qemu's shouldn't be too upset if it's missing. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210809170956.78536-1-dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit da77adbaf619c4d170cb42d769145ad1803fbad9) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/sd/sdcard: Fix assertion accessing out-of-range addresses with CMD30Philippe Mathieu-Daudé1-1/+1
OSS-Fuzz found sending illegal addresses when querying the write protection bits triggers the assertion added in commit 84816fb63e5 ("hw/sd/sdcard: Assert if accessing an illegal group"): qemu-fuzz-i386-target-generic-fuzz-sdhci-v3: ../hw/sd/sd.c:824: uint32_t sd_wpbits(SDState *, uint64_t): Assertion `wpnum < sd->wpgrps_size' failed. #3 0x7f62a8b22c91 in __assert_fail #4 0x5569adcec405 in sd_wpbits hw/sd/sd.c:824:9 #5 0x5569adce5f6d in sd_normal_command hw/sd/sd.c:1389:38 #6 0x5569adce3870 in sd_do_command hw/sd/sd.c:1737:17 #7 0x5569adcf1566 in sdbus_do_command hw/sd/core.c:100:16 #8 0x5569adcfc192 in sdhci_send_command hw/sd/sdhci.c:337:12 #9 0x5569adcfa3a3 in sdhci_write hw/sd/sdhci.c:1186:9 #10 0x5569adfb3447 in memory_region_write_accessor softmmu/memory.c:492:5 It is legal for the CMD30 to query for out-of-range addresses. Such invalid addresses are simply ignored in the response (write protection bits set to 0). In commit 84816fb63e5 ("hw/sd/sdcard: Assert if accessing an illegal group") we misplaced the assertion *before* we test the address is in range. Move it *after*. Include the qtest reproducer provided by Alexander Bulekov: $ make check-qtest-i386 ... Running test qtest-i386/fuzz-sdcard-test qemu-system-i386: ../hw/sd/sd.c:824: sd_wpbits: Assertion `wpnum < sd->wpgrps_size' failed. Cc: qemu-stable@nongnu.org Reported-by: OSS-Fuzz (Issue 29225) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 84816fb63e5 ("hw/sd/sdcard: Assert if accessing an illegal group") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/495 Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210802235524.3417739-3-f4bug@amsat.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> (cherry picked from commit 4ac0b72bae85cf94ae0e5153b9c2c288c71667d4) *drop fuzz test additions, since sdcard fuzz test has functional dependency on guest-visible change not flagged for stable: 59b63d78 ("hw/sd/sdcard: Check for valid address range in SEND_WRITE_PROT (CMD30)") Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/sd/sdcard: Document out-of-range addresses for SEND_WRITE_PROTPhilippe Mathieu-Daudé1-1/+8
Per the 'Physical Layer Simplified Specification Version 3.01', Table 4-22: 'Block Oriented Write Protection Commands' SEND_WRITE_PROT (CMD30) If the card provides write protection features, this command asks the card to send the status of the write protection bits [1]. [1] 32 write protection bits (representing 32 write protect groups starting at the specified address) [...] The last (least significant) bit of the protection bits corresponds to the first addressed group. If the addresses of the last groups are outside the valid range, then the corresponding write protection bits shall be set to 0. Split the if() statement (without changing the behaviour of the code) to better position the description comment. Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210802235524.3417739-2-f4bug@amsat.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> (cherry picked from commit 2a0396285daa9483459ec1d3791951300b595e85) *context dependency for 4ac0b72bae ("hw/sd/sdcard: Fix assertion accessing out-of-range addresses with CMD30") Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/net/can: sja1000 fix buff2frame_bas and buff2frame_pel when dlc is out of ↵Pavel Pisa1-0/+8
std CAN 8 bytes Problem reported by openEuler fuzz-sig group. The buff2frame_bas function (hw\net\can\can_sja1000.c) infoleak(qemu5.x~qemu6.x) or stack-overflow(qemu 4.x). Reported-by: Qiang Ning <ningqiang1@huawei.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 11744862f27b9ba6488a247d2fd6bb83d9bc3c8d) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14virtio-balloon: don't start free page hinting if postcopy is possibleDavid Hildenbrand1-0/+13
Postcopy never worked properly with 'free-page-hint=on', as there are at least two issues: 1) With postcopy, the guest will never receive a VIRTIO_BALLOON_CMD_ID_DONE and consequently won't release free pages back to the OS once migration finishes. The issue is that for postcopy, we won't do a final bitmap sync while the guest is stopped on the source and virtio_balloon_free_page_hint_notify() will only call virtio_balloon_free_page_done() on the source during PRECOPY_NOTIFY_CLEANUP, after the VM state was already migrated to the destination. 2) Once the VM touches a page on the destination that has been excluded from migration on the source via qemu_guest_free_page_hint() while postcopy is active, that thread will stall until postcopy finishes and all threads are woken up. (with older Linux kernels that won't retry faults when woken up via userfaultfd, we might actually get a SEGFAULT) The issue is that the source will refuse to migrate any pages that are not marked as dirty in the dirty bmap -- for example, because the page might just have been sent. Consequently, the faulting thread will stall, waiting for the page to be migrated -- which could take quite a while and result in guest OS issues. While we could fix 1) comparatively easily, 2) is harder to get right and might require more involved RAM migration changes on source and destination [1]. As it never worked properly, let's not start free page hinting in the precopy notifier if the postcopy migration capability was enabled to fix it easily. Capabilities cannot be enabled once migration is already running. Note 1: in the future we might either adjust migration code on the source to track pages that have actually been sent or adjust migration code on source and destination to eventually send pages multiple times from the source and and deal with pages that are sent multiple times on the destination. Note 2: virtio-mem has similar issues, however, access to "unplugged" memory by the guest is very rare and we would have to be very lucky for it to happen during migration. The spec states "The driver SHOULD NOT read from unplugged memory blocks ..." and "The driver MUST NOT write to unplugged memory blocks". virtio-mem will move away from virtio_balloon_free_page_done() soon and handle this case explicitly on the destination. [1] https://lkml.kernel.org/r/e79fd18c-aa62-c1d8-c7f3-ba3fc2c25fc8@redhat.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> Cc: Juan Quintela <quintela@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210708095339.20274-2-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit fd51e54fa10221e5a8add894c38cc1cf199f4bc4) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/nvme: fix pin-based interrupt behavior (again)Klaus Jensen2-1/+18
Jakub noticed[1] that, when using pin-based interrupts, the device will unconditionally deasssert when any CQEs are acknowledged. However, the pin should not be deasserted if other completion queues still holds unacknowledged CQEs. The bug is an artifact of commit ca247d35098d ("hw/block/nvme: fix pin-based interrupt behavior") which fixed one bug but introduced another. This is the third time someone tries to fix pin-based interrupts (see commit 5e9aa92eb1a5 ("hw/block: Fix pin-based interrupt behaviour of NVMe"))... Third time's the charm, so fix it, again, by keeping track of how many CQs have unacknowledged CQEs and only deassert when all are cleared. [1]: <20210610114624.304681-1-jakub.jermar@kernkonzept.com> Cc: qemu-stable@nongnu.org Fixes: ca247d35098d ("hw/block/nvme: fix pin-based interrupt behavior") Reported-by: Jakub Jermář <jakub.jermar@kernkonzept.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Keith Busch <kbusch@kernel.org> (cherry picked from commit 83d7ed5c570d4c1d5163951b3057cac2ae7da4ff) *avoid dependency on 88eea45c ("hw/nvme: move nvme emulation out of hw/block") Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/nvme: fix missing check for PMR capabilityKlaus Jensen1-0/+4
Qiang Liu reported that an access on an unknown address is triggered in memory_region_set_enabled because a check on CAP.PMRS is missing for the PMRCTL register write when no PMR is configured. Cc: qemu-stable@nongnu.org Fixes: 75c3c9de961d ("hw/block/nvme: disable PMR at boot up") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/362 Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Keith Busch <kbusch@kernel.org> (cherry picked from commit 2b02aabc9d02f9e95946cf639f546bb61f1721b7) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/block/nvme: align with existing styleGollu Appalanaidu3-35/+44
While QEMU coding style prefers lowercase hexadecimals in constants, the NVMe subsystem uses the format from the NVMe specifications in comments, i.e. 'h' suffix instead of '0x' prefix. Fix this up across the code base. Signed-off-by: Gollu Appalanaidu <anaidu.gollu@samsung.com> [k.jensen: updated message; added conversion in a couple of missing comments] Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 312c3531bba416e589f106db8c8241fc6e7e6332) *context dependency for 2b02aabc9d Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14tests: acpi: pc: update expected DSDT blobsIgor Mammedov11-10/+0
@@ -930,20 +930,20 @@ DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPC ", 0x00000001) Device (S00) { Name (_ADR, Zero) // _ADR: Address - Name (_SUN, Zero) // _SUN: Slot User Number + Name (ASUN, Zero) Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { - Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN)) + Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN)) } } Device (S10) { Name (_ADR, 0x00020000) // _ADR: Address - Name (_SUN, 0x02) // _SUN: Slot User Number + Name (ASUN, 0x02) Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { - Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN)) + Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN)) } Method (_S1D, 0, NotSerialized) // _S1D: S1 Device State with a hank per bridge: @@ -965,10 +965,10 @@ DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPC ", 0x00000001) Device (S18) { Name (_ADR, 0x00030000) // _ADR: Address - Name (_SUN, 0x03) // _SUN: Slot User Number + Name (ASUN, 0x03) Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { - Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN)) + Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN)) } } Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210624204229.998824-4-imammedo@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: John Sucaet <john.sucaet@ekinops.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 40f23e4e52f6188036062abea432560e5cdd239a) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14acpi: pc: revert back to v5.2 PCI slot enumerationIgor Mammedov1-2/+7
Commit [1] moved _SUN variable from only hot-pluggable to all devices. This made linux kernel enumerate extra slots that weren't present before. If extra slot happens to be be enumerated first and there is a device in th same slot but on other bridge, linux kernel will add -N suffix to slot name of the later, thus changing NIC name compared to QEMU 5.2. This in some case confuses systemd, if it is using SLOT NIC naming scheme and interface name becomes not the same as it was under QEMU-5.2. Reproducer QEMU CLI: -M pc-i440fx-5.2 -nodefaults \ -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x3 \ -device virtio-net-pci,id=nic1,bus=pci.1,addr=0x1 \ -device virtio-net-pci,id=nic2,bus=pci.1,addr=0x2 \ -device virtio-net-pci,id=nic3,bus=pci.1,addr=0x3 with RHEL8 guest produces following results: v5.2: kernel: virtio_net virtio0 ens1: renamed from eth0 kernel: virtio_net virtio2 ens3: renamed from eth2 kernel: virtio_net virtio1 enp1s2: renamed from eth1 (slot 2 is assigned to empty bus 0 slot and virtio1 is assigned to 2-2 slot, and renaming falls back, for some reason, to path based naming scheme) v6.0: kernel: virtio_net virtio0 ens1: renamed from eth0 kernel: virtio_net virtio2 ens3: renamed from eth2 systemd-udevd[299]: Error changing net interface name 'eth1' to 'ens3': File exists systemd-udevd[299]: could not rename interface '3' from 'eth1' to 'ens3': File exists (with commit [1] kernel assigns virtio2 to 3-2 slot since bridge advertises _SUN=0x3 and kernel assigns slot 3 to bridge. Still it manages to rename virtio2 correctly to ens3, however systemd gets confused with virtio1 where slot allocation exactly the same (2-2) as in 5.2 case and tries to rename it to ens3 which is rightfully taken by virtio2) I'm not sure what breaks in systemd interface renaming (it probably should be investigated), but on QEMU side we can safely revert _SUN to 5.2 behavior (i.e. avoid cold-plugged bridges and non hot-pluggable device classes), without breaking acpi-index, which uses slot numbers but it doesn't have to use _SUN, it could use an arbitrary variable name that has the same slot value). It will help existing VMs to keep networking with non trivial configs in working order since systemd will do its interface renaming magic as it used to do. 1) Fixes: b7f23f62e40 (pci: acpi: add _DSM method to PCI devices) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210624204229.998824-3-imammedo@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: John Sucaet <john.sucaet@ekinops.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 7193d7cdd93e50f0e5f09803b98d27d3f9b147ac) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14tests: acpi: prepare for changing DSDT tablesIgor Mammedov1-0/+10
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210624204229.998824-2-imammedo@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: John Sucaet <john.sucaet@ekinops.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a4344574fd47336b6d8fc85ce1f66d4262e7dafd) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14yank: Unregister function when using TLS migrationLeonardo Bras3-14/+19
After yank feature was introduced in migration, whenever migration is started using TLS, the following error happens in both source and destination hosts: (qemu) qemu-kvm: ../util/yank.c:107: yank_unregister_instance: Assertion `QLIST_EMPTY(&entry->yankfns)' failed. This happens because of a missing yank_unregister_function() when using qio-channel-tls. Fix this by also allowing TYPE_QIO_CHANNEL_TLS object type to perform yank_unregister_function() in channel_close() and multifd_load_cleanup(). Also, inside migration_channel_connect() and migration_channel_process_incoming() move yank_register_function() so it only runs once on a TLS migration. Fixes: b5eea99ec2f ("migration: Add yank feature", 2021-01-13) Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1964326 Signed-off-by: Leonardo Bras <leobras.c@gmail.com> Reviewed-by: Lukas Straub <lukasstraub2@web.de> Reviewed-by: Peter Xu <peterx@redhat.com> -- Changes since v2: - Dropped all references to ioc->master - yank_register_function() and yank_unregister_function() now only run once in a TLS migration. Changes since v1: - Cast p->c to QIOChannelTLS into multifd_load_cleanup() Message-Id: <20210601054030.1153249-1-leobras.c@gmail.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 7de2e8565335c13fb3516cddbe2e40e366cce273) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14crypto: Make QCryptoTLSCreds* structures privatePhilippe Mathieu-Daudé11-56/+58
Code consuming the "crypto/tlscreds*.h" APIs doesn't need to access its internals. Move the structure definitions to the "tlscredspriv.h" private header (only accessible by implementations). The public headers (in include/) still forward-declare the structures typedef. Note, tlscreds.c and 3 of the 5 modified source files already include "tlscredspriv.h", so only add it to tls-cipher-suites.c and tlssession.c. Removing the internals from the public header solves a bug introduced by commit 7de2e856533 ("yank: Unregister function when using TLS migration") which made migration/qemu-file-channel.c include "io/channel-tls.h", itself sometime depends on GNUTLS, leading to a build failure on OSX: [2/35] Compiling C object libmigration.fa.p/migration_qemu-file-channel.c.o FAILED: libmigration.fa.p/migration_qemu-file-channel.c.o cc -Ilibmigration.fa.p -I. -I.. -Iqapi [ ... ] -o libmigration.fa.p/migration_qemu-file-channel.c.o -c ../migration/qemu-file-channel.c In file included from ../migration/qemu-file-channel.c:29: In file included from include/io/channel-tls.h:26: In file included from include/crypto/tlssession.h:24: include/crypto/tlscreds.h:28:10: fatal error: 'gnutls/gnutls.h' file not found #include <gnutls/gnutls.h> ^~~~~~~~~~~~~~~~~ 1 error generated. Reported-by: Stefan Weil <sw@weilnetz.de> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/407 Fixes: 7de2e856533 ("yank: Unregister function when using TLS migration") Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 678bcc3c2cf22262d0a72b52da57737c4a40e040) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14ui/vnc: Use qcrypto_tls_creds_check_endpoint()Philippe Mathieu-Daudé1-3/+4
Avoid accessing QCryptoTLSCreds internals by using the qcrypto_tls_creds_check_endpoint() helper. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 3c52bf0c608419d7892fea95f2a0af8f2e99633e) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14migration/tls: Use qcrypto_tls_creds_check_endpoint()Philippe Mathieu-Daudé1-5/+1
Avoid accessing QCryptoTLSCreds internals by using the qcrypto_tls_creds_check_endpoint() helper. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 5590f65facc508fbc38575f19a0ab2fdcdcf18a4) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14chardev/socket: Use qcrypto_tls_creds_check_endpoint()Philippe Mathieu-Daudé1-12/+6
Avoid accessing QCryptoTLSCreds internals by using the qcrypto_tls_creds_check_endpoint() helper. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 8612df2ebef9ff1f880fe76d223a3369b9c98db2) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14qemu-nbd: Use qcrypto_tls_creds_check_endpoint()Philippe Mathieu-Daudé1-12/+7
Avoid accessing QCryptoTLSCreds internals by using the qcrypto_tls_creds_check_endpoint() helper. Tested-by: Akihiko Odaki <akihiko.odaki@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 0279cd9535283cf5711768ab6401b204e5697a81) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14block/nbd: Use qcrypto_tls_creds_check_endpoint()Philippe Mathieu-Daudé2-6/+6
Avoid accessing QCryptoTLSCreds internals by using the qcrypto_tls_creds_check_endpoint() helper. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 7b3b616838c30830c004b746e7b1209297118318) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14crypto/tlscreds: Introduce qcrypto_tls_creds_check_endpoint() helperPhilippe Mathieu-Daudé2-0/+26
Introduce the qcrypto_tls_creds_check_endpoint() helper to access QCryptoTLSCreds internal 'endpoint' field. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit e9ac68083f26759b85ef0d871ca2bbe897218f64) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14block/nvme: Fix VFIO_MAP_DMA failed: No space left on devicePhilippe Mathieu-Daudé1-0/+22
When the NVMe block driver was introduced (see commit bdd6a90a9e5, January 2018), Linux VFIO_IOMMU_MAP_DMA ioctl was only returning -ENOMEM in case of error. The driver was correctly handling the error path to recycle its volatile IOVA mappings. To fix CVE-2019-3882, Linux commit 492855939bdb ("vfio/type1: Limit DMA mappings per container", April 2019) added the -ENOSPC error to signal the user exhausted the DMA mappings available for a container. The block driver started to mis-behave: qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device (qemu) (qemu) info status VM status: paused (io-error) (qemu) c VFIO_MAP_DMA failed: No space left on device (qemu) c VFIO_MAP_DMA failed: No space left on device (The VM is not resumable from here, hence stuck.) Fix by handling the new -ENOSPC error (when DMA mappings are exhausted) without any distinction to the current -ENOMEM error, so we don't change the behavior on old kernels where the CVE-2019-3882 fix is not present. An easy way to reproduce this bug is to restrict the DMA mapping limit (65535 by default) when loading the VFIO IOMMU module: # modprobe vfio_iommu_type1 dma_entry_limit=666 Cc: qemu-stable@nongnu.org Cc: Fam Zheng <fam@euphon.net> Cc: Maxim Levitsky <mlevitsk@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Reported-by: Michal Prívozník <mprivozn@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210723195843.1032825-1-philmd@redhat.com Fixes: bdd6a90a9e5 ("block: Add VFIO based NVMe driver") Buglink: https://bugs.launchpad.net/qemu/+bug/1863333 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/65 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 15a730e7a3aaac180df72cd5730e0617bcf44a5a) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH fieldPhilippe Mathieu-Daudé1-0/+3
libFuzzer triggered the following assertion: cat << EOF | qemu-system-i386 -M pc-q35-5.0 \ -nographic -monitor none -serial none \ -qtest stdio -d guest_errors -trace pci\* outl 0xcf8 0xf2000060 outl 0xcfc 0x8400056e EOF pci_cfg_write mch 00:0 @0x60 <- 0x8400056e Aborted (core dumped) This is because guest wrote MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD (reserved value) to the PCIE XBAR register. There is no indication on the datasheet about what occurs when this value is written. Simply ignore it on QEMU (and report an guest error): pci_cfg_write mch 00:0 @0x60 <- 0x8400056e Q35: Reserved PCIEXBAR LENGTH pci_cfg_read mch 00:0 @0x0 -> 0x8086 pci_cfg_read mch 00:0 @0x0 -> 0x29c08086 ... Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> BugLink: https://bugs.launchpad.net/qemu/+bug/1878641 Fixes: df2d8b3ed4 ("q35: Introduce q35 pc based chipset emulator") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210526142438.281477-1-f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 9b0ca75e0196a72523232063db1e07ae36a5077a) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14tcg: Allocate sufficient storage in temp_allocate_frameRichard Henderson1-5/+26
This function should have been updated for vector types when they were introduced. Fixes: d2fd745fe8b Resolves: https://gitlab.com/qemu-project/qemu/-/issues/367 Cc: qemu-stable@nongnu.org Tested-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit c1c091948ae4a73c1a80b5005f6204d0e665ce52) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14tcg/sparc: Fix temp_allocate_frame vs sparc stack biasRichard Henderson2-12/+13
We should not be aligning the offset in temp_allocate_frame, because the odd offset produces an aligned address in the end. Instead, pass the logical offset into tcg_set_frame and add the stack bias last. Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 9defd1bdfb0f2ddb3ca9863e39577f3a9929d58c) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14vl: Fix an assert failure in error pathZhenzhong Duan1-1/+1
Based on the description of error_setg(), the local variable err in qemu_maybe_daemonize() should be initialized to NULL. Without fix, the uninitialized *errp triggers assert failure which doesn't show much valuable information. Before the fix: qemu-system-x86_64: ../util/error.c:59: error_setv: Assertion `*errp == NULL' failed. After fix: qemu-system-x86_64: cannot create PID file: Cannot open pid file: Permission denied Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20210610084741.456260-1-zhenzhong.duan@intel.com> Cc: qemu-stable@nongnu.org Fixes: 0546c0609c ("vl: split various early command line options to a separate function", 2020-12-10) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 38f71349c7c4969bc14da4da1c70b8cc4078d596) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14vfio: Fix unregister SaveVMHandler in vfio_migration_finalizeKunkun Jiang1-0/+1
In the vfio_migration_init(), the SaveVMHandler is registered for VFIO device. But it lacks the operation of 'unregister'. It will lead to 'Segmentation fault (core dumped)' in qemu_savevm_state_setup(), if performing live migration after a VFIO device is hot deleted. Fixes: 7c2f5f75f94 (vfio: Register SaveVMHandlers for VFIO device) Reported-by: Qixin Gan <ganqixin@huawei.com> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> Message-Id: <20210527123101.289-1-jiangkunkun@huawei.com> Reviewed by: Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> (cherry picked from commit 22fca190e25b10761925bb1eeadeda07aabf3c26) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14runstate: Initialize Error * to NULLPeng Liang1-1/+1
Based on the description of error_setg(), the local variable err in qemu_init_subsystems() should be initialized to NULL. Fixes: efd7ab22fb ("vl: extract qemu_init_subsystems") Cc: qemu-stable@nongnu.org Signed-off-by: Peng Liang <liangpeng10@huawei.com> Message-Id: <20210610131729.3906565-1-liangpeng10@huawei.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 6e1da3d305499d3907f3c7f6638243e2e09b5085) Signed-off-by: Michael Roth <michael.roth@amd.com>
2021-10-14esp: only set ESP_RSEQ at the start of the select sequenceMark Cave-Ayland1-2/+9
When processing a command to select a target and send a CDB, the ESP device maintains a sequence step register so that if an error occurs the host can determine which part of the selection/CDB submission sequence failed. The old Linux 2.6 driver is really pedantic here: it checks the sequence step register even if a command succeeds and complains loudly on the console if the sequence step register doesn't match the expected bus phase and interrupt flags. This reason this mismatch occurs is because the ESP emulation currently doesn't update the bus phase until the next TI (Transfer Information) command and so the cleared sequence step register is considered invalid for the stale bus phase. Normally this isn't an issue as the host only checks the sequence step register if an error occurs but the old Linux 2.6 driver does this in several places causing a large stream of "esp0: STEP_ASEL for tgt 0" messages to appear on the console during the boot process. Fix this by not clearing the sequence step register when reading the interrupt register and clearing the DMA status, so the guest sees a valid sequence step and bus phase combination at the end of the command phase. No other change is required since the sequence step register is correctly updated throughout the selection/CDB submission sequence once one of the select commands is issued. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 1b9e48a5bd ("esp: implement non-DMA transfers in PDMA mode") Message-Id: <20210518212511.21688-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit af947a3d853a235943681a00f07f3081f5143cc3) Signed-off-by: Michael Roth <michael.roth@amd.com>
generated by cgit v1.1 at 2024-09-10 15:59:52 +0000