Skip to main content

Browse the archive

https://github.com/qemu/qemu
04 August 2024, 22:51:34 UTC
sort by:
Revision Author Date Message Commit Date
6cdf8c4 Michael Roth 25 June 2020, 18:08:54 UTC Update version for 4.2.1 release 25 June 2020, 18:08:54 UTC
4a0db6b Kevin Wolf 30 April 2020, 14:27:52 UTC iotests/283: Use consistent size for source and target 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> 22 June 2020, 18:03:59 UTC
0664ffa Helge Deller 26 April 2020, 10:55:39 UTC Fix tulip breakage 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> 22 June 2020, 18:03:08 UTC
27f56b9 lixinyu 11 April 2020, 12:46:12 UTC tcg/mips: mips sync* encode error OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and OPC_SYNC_RMB have wrong encode. According to the mips manual, their encode should be 'OPC_SYNC | 0x?? << 6' rather than 'OPC_SYNC | 0x?? << 5'. Wrong encode can lead illegal instruction errors. These instructions often appear with multi-threaded simulation. Fixes: 6f0b99104a3 ("tcg/mips: Add support for fence") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: lixinyu <precinct@mail.ustc.edu.cn> Message-Id: <20200411124612.12560-1-precinct@mail.ustc.edu.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit a4e57084c16d5b0eff3651693fba04f26b30b551) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:53:09 UTC
97701bc Max Filippov 26 February 2020, 20:43:52 UTC target/xtensa: fix pasto in pfwait.r opcode name Core xtensa opcode table has pfwait.o instead of pfwait.r. Fix that. Fixes: c884400f2988 ("target/xtensa: implement block prefetch option opcodes") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 1a03362b14affa4d8ddede55df6e21d7a07b87c2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:55 UTC
ecdb0d5 Kevin Wolf 02 April 2020, 09:36:03 UTC vpc: Don't round up already aligned BAT sizes As reported on Launchpad, Azure apparently doesn't accept images for upload that are not both aligned to 1 MB blocks and have a BAT size that matches the image size exactly. As far as I can tell, there is no real reason why we create a BAT that is one entry longer than necessary for aligned image sizes, so change that. (Even though the condition is only mentioned as "should" in the spec and previous products accepted larger BATs - but we'll try to maintain compatibility with as many of Microsoft's ever-changing interpretations of the VHD spec as possible.) Fixes: https://bugs.launchpad.net/bugs/1870098 Reported-by: Tobias Witek Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200402093603.2369-1-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 3f6de653b946fe849330208becf79d6af7e876cb) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:50 UTC
9c2e242 David Gibson 26 March 2020, 05:12:40 UTC spapr: Fix failure path for attempting to hot unplug PCI bridges For various technical reasons we can't currently allow unplug a PCI to PCI bridge on the pseries machine. spapr_pci_unplug_request() correctly generates an error message if that's attempted. But.. if the given errp is not error_abort or error_fatal, it doesn't actually stop trying to unplug the bridge anyway. Fixes: 14e714900f6b "spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges" Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 7aab5899764887f6b0512cb2e5c11bdc2a5d3644) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:45 UTC
fb6a24f Prasad J Pandit 24 March 2020, 17:27:22 UTC net: tulip: check frame size and r/w data length Tulip network driver while copying tx/rx buffers does not check frame size against r/w data length. This may lead to OOB buffer access. Add check to avoid it. Limit iterations over descriptors to avoid potential infinite loop issue in tulip_xmit_list_update. Reported-by: Li Qiang <pangpei.lq@antfin.com> Reported-by: Ziming Zhang <ezrakiez@gmail.com> Reported-by: Jason Wang <jasowang@redhat.com> Tested-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 8ffb7265af64ec81748335ec8f20e7ab542c3850) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:33 UTC
60c21aa Eric Blake 24 March 2020, 17:42:33 UTC sheepdog: Consistently set bdrv_has_zero_init_truncate block_int.h claims that .bdrv_has_zero_init must return 0 if .bdrv_has_zero_init_truncate does likewise; but this is violated if only the former callback is provided if .bdrv_co_truncate also exists. When adding the latter callback, it was mistakenly added to only one of the three possible sheepdog instantiations. Fixes: 1dcaf527 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200324174233.1622067-5-eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit ed049910637be991c88cc25c864115bc5b1e4dab) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:29 UTC
5eca12b Eric Blake 24 March 2020, 17:42:31 UTC qcow2: List autoclear bit names in header The feature table is supposed to advertise the name of all feature bits that we support; however, we forgot to update the table for autoclear bits. While at it, move the table to read-only memory in code, and tweak the qcow2 spec to name the second autoclear bit. Update iotests that are affected by the longer header length. Fixes: 88ddffae Fixes: 93c24936 Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200324174233.1622067-3-eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit bb40ebce2cb0bd4bf37968074d43d5a864fb6dee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:24 UTC
1c8d9fb Vladimir Sementsov-Ogievskiy 24 March 2020, 15:36:29 UTC migration/ram: fix use after free of local_err local_err is used again in migration_bitmap_sync_precopy() after precopy_notify(), so we must zero it. Otherwise try to set non-NULL local_err will crash. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200324153630.11882-6-vsementsov@virtuozzo.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit b4a1733c5e6827c72b0dcfa295e07ef7b1ebccff) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:20 UTC
09397e9 Vladimir Sementsov-Ogievskiy 24 March 2020, 15:36:28 UTC migration/colo: fix use after free of local_err local_err is used again in secondary_vm_do_failover() after replication_stop_all(), so we must zero it. Otherwise try to set non-NULL local_err will crash. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200324153630.11882-5-vsementsov@virtuozzo.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 27d07fcfa70c3afa0664288cbce5334ed9595a3a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:16 UTC
674d382 Dr. David Alan Gilbert 23 March 2020, 12:08:22 UTC hmp/vnc: Fix info vnc list leak We're iterating the list, and then freeing the iteration pointer rather than the list head. Fixes: 0a9667ecdb6d ("hmp: Update info vnc") Reported-by: Coverity (CID 1421932) Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200323120822.51266-1-dgilbert@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit d4ff109373ce871928c7e9ef648973eba642b484) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:12 UTC
5ff78dc Vladimir Sementsov-Ogievskiy 16 March 2020, 06:06:30 UTC block: bdrv_set_backing_bs: fix use-after-free There is a use-after-free possible: bdrv_unref_child() leaves bs->backing freed but not NULL. bdrv_attach_child may produce nested polling loop due to drain, than access of freed pointer is possible. I've produced the following crash on 30 iotest with modified code. It does not reproduce on master, but still seems possible: #0 __strcmp_avx2 () at /lib64/libc.so.6 #1 bdrv_backing_overridden (bs=0x55c9d3cc2060) at block.c:6350 #2 bdrv_refresh_filename (bs=0x55c9d3cc2060) at block.c:6404 #3 bdrv_backing_attach (c=0x55c9d48e5520) at block.c:1063 #4 bdrv_replace_child_noperm (child=child@entry=0x55c9d48e5520, new_bs=new_bs@entry=0x55c9d3cc2060) at block.c:2290 #5 bdrv_replace_child (child=child@entry=0x55c9d48e5520, new_bs=new_bs@entry=0x55c9d3cc2060) at block.c:2320 #6 bdrv_root_attach_child (child_bs=child_bs@entry=0x55c9d3cc2060, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, ctx=<optimized out>, perm=<optimized out>, shared_perm=21, opaque=0x55c9d3c5a3d0, errp=0x7ffd117108e0) at block.c:2424 #7 bdrv_attach_child (parent_bs=parent_bs@entry=0x55c9d3c5a3d0, child_bs=child_bs@entry=0x55c9d3cc2060, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, errp=errp@entry=0x7ffd117108e0) at block.c:5876 #8 in bdrv_set_backing_hd (bs=bs@entry=0x55c9d3c5a3d0, backing_hd=backing_hd@entry=0x55c9d3cc2060, errp=errp@entry=0x7ffd117108e0) at block.c:2576 #9 stream_prepare (job=0x55c9d49d84a0) at block/stream.c:150 #10 job_prepare (job=0x55c9d49d84a0) at job.c:761 #11 job_txn_apply (txn=<optimized out>, fn=<optimized out>) at job.c:145 #12 job_do_finalize (job=0x55c9d49d84a0) at job.c:778 #13 job_completed_txn_success (job=0x55c9d49d84a0) at job.c:832 #14 job_completed (job=0x55c9d49d84a0) at job.c:845 #15 job_completed (job=0x55c9d49d84a0) at job.c:836 #16 job_exit (opaque=0x55c9d49d84a0) at job.c:864 #17 aio_bh_call (bh=0x55c9d471a160) at util/async.c:117 #18 aio_bh_poll (ctx=ctx@entry=0x55c9d3c46720) at util/async.c:117 #19 aio_poll (ctx=ctx@entry=0x55c9d3c46720, blocking=blocking@entry=true) at util/aio-posix.c:728 #20 bdrv_parent_drained_begin_single (poll=true, c=0x55c9d3d558f0) at block/io.c:121 #21 bdrv_parent_drained_begin_single (c=c@entry=0x55c9d3d558f0, poll=poll@entry=true) at block/io.c:114 #22 bdrv_replace_child_noperm (child=child@entry=0x55c9d3d558f0, new_bs=new_bs@entry=0x55c9d3d27300) at block.c:2258 #23 bdrv_replace_child (child=child@entry=0x55c9d3d558f0, new_bs=new_bs@entry=0x55c9d3d27300) at block.c:2320 #24 bdrv_root_attach_child (child_bs=child_bs@entry=0x55c9d3d27300, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, ctx=<optimized out>, perm=<optimized out>, shared_perm=21, opaque=0x55c9d3cc2060, errp=0x7ffd11710c60) at block.c:2424 #25 bdrv_attach_child (parent_bs=parent_bs@entry=0x55c9d3cc2060, child_bs=child_bs@entry=0x55c9d3d27300, child_name=child_name@entry=0x55c9d241d478 "backing", child_role=child_role@entry=0x55c9d26ecee0 <child_backing>, errp=errp@entry=0x7ffd11710c60) at block.c:5876 #26 bdrv_set_backing_hd (bs=bs@entry=0x55c9d3cc2060, backing_hd=backing_hd@entry=0x55c9d3d27300, errp=errp@entry=0x7ffd11710c60) at block.c:2576 #27 stream_prepare (job=0x55c9d495ead0) at block/stream.c:150 ... Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200316060631.30052-2-vsementsov@virtuozzo.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 6e57963a77df1e275a73dab4c6a7ec9a9d3468d4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:06 UTC
47e0fa7 Eric Blake 20 March 2020, 18:36:20 UTC block: Avoid memleak on qcow2 image info failure If we fail to get bitmap info, we must not leak the encryption info. Fixes: b8968c875f403 Fixes: Coverity CID 1421894 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200320183620.1112123-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Tested-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 71eaec2e8c7c8d266137b5c5f42da0bd6d6b5eb7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:52:01 UTC
745859d Philippe Mathieu-Daudé 20 March 2020, 15:57:40 UTC ppc/ppc405_boards: Remove unnecessary NULL check This code is inside the "if (dinfo)" condition, so testing again here whether it is NULL is unnecessary. Fixes: dd59bcae7 (Don't size flash memory to match backing image) Reported-by: Coverity (CID 1421917) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200320155740.5342-1-philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 1583794b9b36911df116cc726750dadbeeac506a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:51:56 UTC
c6decab Eric Blake 26 February 2020, 12:54:24 UTC iotests: Fix nonportable use of od --endian Tests 261 and 272 fail on RHEL 7 with coreutils 8.22, since od --endian was not added until coreutils 8.23. Fix this by manually constructing the final value one byte at a time. Fixes: fc8ba423 Reported-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200226125424.481840-1-eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 69135eb30b9c3fca583737a96df015174dc8e6dd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:51:50 UTC
580c08b Janosch Frank 04 March 2020, 11:42:31 UTC pc-bios: s390x: Save iplb location in lowcore The POP states that for a list directed IPL the IPLB is stored into memory by the machine loader and its address is stored at offset 0x14 of the lowcore. ZIPL currently uses the address in offset 0x14 to access the IPLB and acquire flags about secure boot. If the IPLB address points into memory which has an unsupported mix of flags set, ZIPL will panic instead of booting the OS. As the lowcore can have quite a high entropy for a guest that did drop out of protected mode (i.e. rebooted) we encountered the ZIPL panic quite often. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-Id: <20200304114231.23493-19-frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> (cherry picked from commit 9bfc04f9ef6802fff0fc77130ff345a541783363) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:51:41 UTC
9dd68ac Niek Linnenbank 05 March 2020, 16:09:19 UTC hw/arm/cubieboard: use ARM Cortex-A8 as the default CPU in machine definition The Cubieboard is a singleboard computer with an Allwinner A10 System-on-Chip [1]. As documented in the Allwinner A10 User Manual V1.5 [2], the SoC has an ARM Cortex-A8 processor. Currently the Cubieboard machine definition specifies the ARM Cortex-A9 in its description and as the default CPU. This patch corrects the Cubieboard machine definition to use the ARM Cortex-A8. The only user-visible effect is that our textual description of the machine was wrong, because hw/arm/allwinner-a10.c always creates a Cortex-A8 CPU regardless of the default value in the MachineClass struct. [1] http://docs.cubieboard.org/products/start#cubieboard1 [2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf Fixes: 8a863c8120994981a099 Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200227220149.6845-2-nieklinnenbank@gmail.com Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [note in commit message that the bug didn't have much visible effect] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 2104df2a1fbf44b2564427aa72fd58d66ce290a7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:58 UTC
4e258da Pan Nengyuan 24 February 2020, 04:13:35 UTC vhost-user-blk: delete virtioqueues in unrealize to fix memleaks virtio queues forgot to delete in unrealize, and aslo error path in realize, this patch fix these memleaks, the leak stack is as follow: Direct leak of 114688 byte(s) in 16 object(s) allocated from: #0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0) #1 0x7f2401642015 in g_malloc0 (/lib64/libglib-2.0.so.0+0x50015) #2 0x55ad175a6447 in virtio_add_queue /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55ad17570cf9 in vhost_user_blk_device_realize /mnt/sdb/qemu/hw/block/vhost-user-blk.c:419 #4 0x55ad175a3707 in virtio_device_realize /mnt/sdb/qemu/hw/virtio/virtio.c:3509 #5 0x55ad176ad0d1 in device_set_realized /mnt/sdb/qemu/hw/core/qdev.c:876 #6 0x55ad1781ff9d in property_set_bool /mnt/sdb/qemu/qom/object.c:2080 #7 0x55ad178245ae in object_property_set_qobject /mnt/sdb/qemu/qom/qom-qobject.c:26 #8 0x55ad17821eb4 in object_property_set_bool /mnt/sdb/qemu/qom/object.c:1338 #9 0x55ad177aeed7 in virtio_pci_realize /mnt/sdb/qemu/hw/virtio/virtio-pci.c:1801 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200224041336.30790-2-pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 13e5468127111bf44c5dc314d1dd2ec5a65dfec4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:53 UTC
e08de99 Pan Nengyuan 25 February 2020, 07:55:54 UTC virtio-crypto: do delete ctrl_vq in virtio_crypto_device_unrealize Similar to other virtio-deivces, ctrl_vq forgot to delete in virtio_crypto_device_unrealize, this patch fix it. This device has aleardy maintained vq pointers. Thus, we use the new virtio_delete_queue function directly to do the cleanup. The leak stack: Direct leak of 10752 byte(s) in 3 object(s) allocated from: #0 0x7f4c024b1970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f4c018be49d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55a2f8017279 in virtio_add_queue /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:2333 #3 0x55a2f8057035 in virtio_crypto_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto.c:814 #4 0x55a2f8005d80 in virtio_device_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:3531 #5 0x55a2f8497d1b in device_set_realized /mnt/sdb/qemu-new/qemu_test/qemu/hw/core/qdev.c:891 #6 0x55a2f8b48595 in property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:2238 #7 0x55a2f8b54fad in object_property_set_qobject /mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qobject.c:26 #8 0x55a2f8b4de2c in object_property_set_bool /mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:1390 #9 0x55a2f80609c9 in virtio_crypto_pci_realize /mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto-pci.c:58 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Cc: "Gonglei (Arei)" <arei.gonglei@huawei.com> Message-Id: <20200225075554.10835-5-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit d56e1c8256cb37e68f9b5d98c6cc4e6ca463f1fd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:48 UTC
5e063a5 Pan Nengyuan 25 February 2020, 07:55:53 UTC virtio-pmem: do delete rq_vq in virtio_pmem_unrealize Similar to other virtio-devices, rq_vq forgot to delete in virtio_pmem_unrealize, this patch fix it. This device has already maintained a vq pointer, thus we use the new virtio_delete_queue function directly to do the cleanup. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200225075554.10835-4-pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 9861546e1dae05c5152de7d3bd14e341ecadc972) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:39 UTC
1509a13 Peter Maydell 14 February 2020, 17:51:11 UTC target/arm: Correct definition of PMCRDP The PMCR_EL0.DP bit is bit 5, which is 0x20, not 0x10. 0x10 is 'X'. Correct our #define of PMCRDP and add the missing PMCRX. We do have the correct behaviour for handling the DP bit being set, so this fixes a guest-visible bug. Fixes: 033614c47de Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-17-peter.maydell@linaro.org (cherry picked from commit a1ed04dd79aabb9dbeeb5fa7d49f1a3de0357553) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:35 UTC
0b487ea Max Reitz 17 January 2020, 10:58:58 UTC block: Fix VM size field width in snapshot dump When printing the snapshot list (e.g. with qemu-img snapshot -l), the VM size field is only seven characters wide. As of de38b5005e9, this is not necessarily sufficient: We generally print three digits, and this may require a decimal point. Also, the unit field grew from something as plain as "M" to " MiB". This means that number and unit may take up eight characters in total; but we also want spaces in front. Considering previously the maximum width was four characters and the field width was chosen to be three characters wider, let us adjust the field width to be eleven now. Fixes: de38b5005e946aa3714963ea4c501e279e7d3666 Buglink: https://bugs.launchpad.net/qemu/+bug/1859989 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200117105859.241818-2-mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 804359b8b90f76d9d8fbe8d85a6544b68f107f10) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:32 UTC
3dd28c8 Vladimir Sementsov-Ogievskiy 06 February 2020, 16:42:45 UTC block: fix crash on zero-length unaligned write and read Commit 7a3f542fbd "block/io: refactor padding" occasionally dropped aligning for zero-length request: bdrv_init_padding() blindly return false if bytes == 0, like there is nothing to align. This leads the following command to crash: ./qemu-io --image-opts -c 'write 1 0' \ driver=blkdebug,align=512,image.driver=null-co,image.size=512 >> qemu-io: block/io.c:1955: bdrv_aligned_pwritev: Assertion `(offset & (align - 1)) == 0' failed. >> Aborted (core dumped) Prior to 7a3f542fbd we does aligning of such zero requests. Instead of recovering this behavior let's just do nothing on such requests as it is useless. Note that driver may have special meaning of zero-length reqeusts, like qcow2_co_pwritev_compressed_part, so we can't skip any zero-length operation. But for unaligned ones, we can't pass it to driver anyway. This commit also fixes crash in iotest 80 running with -nocache: ./check -nocache -qcow2 80 which crashes on same assertion due to trying to read empty extra data in qcow2_do_read_snapshots(). Cc: qemu-stable@nongnu.org # v4.2 Fixes: 7a3f542fbd Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20200206164245.17781-1-vsementsov@virtuozzo.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit ac9d00bf7b47acae6b0e42910d9ed55fef3af5b8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:27 UTC
ee9f37f Liang Yan 07 February 2020, 14:04:21 UTC target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none Commit e19afd566781 mentioned that target-arm only supports queryable cpu models 'max', 'host', and the current type when KVM is in use. The logic works well until using machine type none. For machine type none, cpu_type will be null if cpu option is not set by command line, strlen(cpu_type) will terminate process. So We add a check above it. This won't affect i386 and s390x since they do not use current_cpu. Signed-off-by: Liang Yan <lyan@suse.com> Message-id: 20200203134251.12986-1-lyan@suse.com Reviewed-by: Andrew Jones <drjones@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 0999a4ba8718aa96105b978d3567fc7e90244c7e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:22 UTC
8952da3 Vladimir Sementsov-Ogievskiy 21 January 2020, 14:28:02 UTC iotests: add test for backup-top failure on permission activation This test checks that bug is really fixed by previous commit. Cc: qemu-stable@nongnu.org # v4.2.0 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20200121142802.21467-3-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit a541fcc27c98b96da187c7d4573f3270f3ddd283) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:50:11 UTC
e92b21f Vladimir Sementsov-Ogievskiy 21 January 2020, 14:28:01 UTC block/backup-top: fix failure path We can't access top after call bdrv_backup_top_drop, as it is already freed at this time. Also, no needs to unref target child by hand, it will be unrefed on bdrv_close() automatically. So, just do bdrv_backup_top_drop if append succeed and one bdrv_unref otherwise. Note, that in !appended case bdrv_unref(top) moved into drained section on source. It doesn't really matter, but just for code simplicity. Fixes: 7df7868b96404 Cc: qemu-stable@nongnu.org # v4.2.0 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20200121142802.21467-2-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 0df62f45c1de6c020f1e6fba4eeafd248209b003) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:49:28 UTC
a967e75 Pan Nengyuan 16 January 2020, 08:56:00 UTC block: fix memleaks in bdrv_refresh_filename If we call the qmp 'query-block' while qemu is working on 'block-commit', it will cause memleaks, the memory leak stack is as follow: Indirect leak of 12360 byte(s) in 3 object(s) allocated from: #0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f80ee86049d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55ea95b5bb67 in qdict_new /mnt/sdb/qemu-4.2.0-rc0/qobject/qdict.c:29 #3 0x55ea956cd043 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6427 #4 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #5 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #6 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #7 0x55ea958818ea in bdrv_block_device_info /mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:56 #8 0x55ea958879de in bdrv_query_info /mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:392 #9 0x55ea9588b58f in qmp_query_block /mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:578 #10 0x55ea95567392 in qmp_marshal_query_block qapi/qapi-commands-block-core.c:95 Indirect leak of 4120 byte(s) in 1 object(s) allocated from: #0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f80ee86049d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55ea95b5bb67 in qdict_new /mnt/sdb/qemu-4.2.0-rc0/qobject/qdict.c:29 #3 0x55ea956cd043 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6427 #4 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #5 0x55ea956cc950 in bdrv_refresh_filename /mnt/sdb/qemu-4.2.0-rc0/block.c:6399 #6 0x55ea9569f301 in bdrv_backing_attach /mnt/sdb/qemu-4.2.0-rc0/block.c:1064 #7 0x55ea956a99dd in bdrv_replace_child_noperm /mnt/sdb/qemu-4.2.0-rc0/block.c:2283 #8 0x55ea956b9b53 in bdrv_replace_node /mnt/sdb/qemu-4.2.0-rc0/block.c:4196 #9 0x55ea956b9e49 in bdrv_append /mnt/sdb/qemu-4.2.0-rc0/block.c:4236 #10 0x55ea958c3472 in commit_start /mnt/sdb/qemu-4.2.0-rc0/block/commit.c:306 #11 0x55ea94b68ab0 in qmp_block_commit /mnt/sdb/qemu-4.2.0-rc0/blockdev.c:3459 #12 0x55ea9556a7a7 in qmp_marshal_block_commit qapi/qapi-commands-block-core.c:407 Fixes: bb808d5f5c0978828a974d547e6032402c339555 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-id: 20200116085600.24056-1-pannengyuan@huawei.com Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit cb8956144ccaccf23d5cc4167677e2c84fa5a9f8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:49:13 UTC
aacf6bf Alex Bennée 31 January 2020, 15:34:39 UTC target/arm: fix TCG leak for fcvt half->double When support for the AHP flag was added we inexplicably only freed the new temps in one of the two legs. Move those tcg_temp_free to the same level as the allocation to fix that leak. Fixes: 486624fcd3eac Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200131153439.26027-1-alex.bennee@linaro.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit aeab8e5eb220cc5ff84b0b68b9afccc611bf0fcd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:49:09 UTC
4b34c6d Gerd Hoffmann 20 January 2020, 10:18:04 UTC audio/oss: fix buffer pos calculation Fixes: 3ba4066d085f ("ossaudio: port to the new audio backend api") Reported-by: ziming zhang <ezrakiez@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20200120101804.29578-1-kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> (cherry picked from commit 7a4ede0047a8613b0e3b72c9d351038f013dd357) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:49:05 UTC
9adb656 Zenghui Yu 30 January 2020, 16:02:05 UTC hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC initialization time". And what's worse, PTZ is generally programmed by guest to indicate to the Redistributor whether the LPI Pending table is zero when enabling LPIs. If migration is triggered when the PTZ has just been cleared by guest (and before enabling LPIs), we will see PTZ==1 on the destination side, which is not as expected. Let's just drop this hackish userspace behavior. Also take this chance to refine the comment a bit. Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Message-id: 20200119133051.642-1-yuzenghui@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 618bacabd3c8c3360be795cd8763bacdf5bec101) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:48:56 UTC
b1b362a Marc-André Lureau 03 January 2020, 07:39:59 UTC tpm-ppi: page-align PPI RAM post-copy migration fails on destination with error such as: 2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range: Unaligned start address: 0x559d2afae9a0 Use qemu_memalign() to constrain the PPI RAM memory alignment. Cc: qemu-stable@nongnu.org Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Message-id: 20200103074000.1006389-3-marcandre.lureau@redhat.com (cherry picked from commit 71e415c8a75c130875f14d6b2136825789feb297) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:48:51 UTC
dc6bdba Eiichi Tsukata 23 December 2019, 09:06:32 UTC block/backup: fix memory leak in bdrv_backup_top_append() bdrv_open_driver() allocates bs->opaque according to drv->instance_size. There is no need to allocate it and overwrite opaque in bdrv_backup_top_append(). Reproducer: $ QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind -q --leak-check=full tests/test-replication -p /replication/secondary/start ==29792== 24 bytes in 1 blocks are definitely lost in loss record 52 of 226 ==29792== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==29792== by 0x4B07CE0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.7) ==29792== by 0x12BAB9: bdrv_open_driver (block.c:1289) ==29792== by 0x12BEA9: bdrv_new_open_driver (block.c:1359) ==29792== by 0x1D15CB: bdrv_backup_top_append (backup-top.c:190) ==29792== by 0x1CC11A: backup_job_create (backup.c:439) ==29792== by 0x1CD542: replication_start (replication.c:544) ==29792== by 0x1401B9: replication_start_all (replication.c:52) ==29792== by 0x128B50: test_secondary_start (test-replication.c:427) ... Fixes: 7df7868b9640 ("block: introduce backup-top filter driver") Signed-off-by: Eiichi Tsukata <devel@etsukata.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit fb574de81bfdd71fdb0315105a3a7761efb68395) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:48:46 UTC
bc509b2 Cornelia Huck 16 January 2020, 12:10:35 UTC s390x: adapter routes error handling If the kernel irqchip has been disabled, we don't want the {add,release}_adapter_routes routines to call any kvm_irqchip_* interfaces, as they may rely on an irqchip actually having been created. Just take a quick exit in that case instead. If you are trying to use irqfd without a kernel irqchip, we will fail with an error. Also initialize routes->gsi[] with -1 in the virtio-ccw handling, to make sure we don't trip over other errors, either. (Nobody else uses the gsi array in that structure.) Fixes: d426d9fba8ea ("s390x/virtio-ccw: wire up irq routing and irqfds") Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200117111147.5006-1-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 3c5fd8074335c67777d9391b84f97070c35d9c63) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:48:41 UTC
cd8ecfb Paolo Bonzini 20 January 2020, 18:21:42 UTC target/i386: kvm: initialize feature MSRs very early Some read-only MSRs affect the behavior of ioctls such as KVM_SET_NESTED_STATE. We can initialize them once and for all right after the CPU is realized, since they will never be modified by the guest. Reported-by: Qingua Cheng <qcheng@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1579544504-3616-2-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 420ae1fc51c99abfd03b1c590f55617edd2a2bed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:48:19 UTC
abf9ffa Vincent Dehors 23 January 2020, 15:22:38 UTC target/arm: Fix PAuth sbox functions In the PAC computation, sbox was applied over wrong bits. As this is a 4-bit sbox, bit index should be incremented by 4 instead of 16. Test vector from QARMA paper (https://eprint.iacr.org/2016/444.pdf) was used to verify one computation of the pauth_computepac() function which uses sbox2. Launchpad: https://bugs.launchpad.net/bugs/1859713 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Vincent DEHORS <vincent.dehors@smile.fr> Signed-off-by: Adrien GRASSEIN <adrien.grassein@smile.fr> Message-id: 20200116230809.19078-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit de0b1bae6461f67243282555475f88b2384a1eb9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:48:11 UTC
c44015c Laurent Vivier 16 January 2020, 16:54:54 UTC m68k: Fix regression causing Single-Step via GDB/RSP to not single step A regression that was introduced, with the refactor to TranslatorOps, drops two lines that update the PC when single-stepping is being performed. Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps") Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200116165454.2076265-1-laurent@vivier.eu> (cherry picked from commit 322f244aaa80a5208090d41481c1c09c6face66b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:47:48 UTC
b5ba361 Gerd Hoffmann 21 January 2020, 06:02:10 UTC Revert "vnc: allow fall back to RAW encoding" This reverts commit de3f7de7f4e257ce44cdabb90f5f17ee99624557. Remove VNC optimization to reencode framebuffer update as raw if it's smaller than the default encoding. QEMU's implementation was naive and didn't account for the ZLIB z_stream mutating with each compression. Because of the mutation, simply resetting the output buffer's offset wasn't sufficient to "rewind" the operation. The mutated z_stream would generate future zlib blocks which referred to symbols in past blocks which weren't sent. This would lead to artifacting. Considering that ZRLE is never larger than raw and even though ZLIB can occasionally be fractionally larger than raw, the overhead of implementing this optimization correctly isn't worth it. Signed-off-by: Cameron Esfahani <dirty@apple.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0780ec7be82dd4781e9fd216b5d99a125882ff5a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:46:27 UTC
52771ab Dr. David Alan Gilbert 05 December 2019, 10:29:18 UTC migration: Rate limit inside host pages When using hugepages, rate limiting is necessary within each huge page, since a 1G huge page can take a significant time to send, so you end up with bursty behaviour. Fixes: 4c011c37ecb3 ("postcopy: Send whole huge pages") Reported-by: Lin Ma <LMa@suse.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit 97e1e06780e70f6e98a0d2df881e0c0927d3aeb6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:46:20 UTC
d306348 Laurent Vivier 29 November 2019, 11:51:32 UTC runstate: ignore finishmigrate -> prelaunch transition Commit 1bd71dce4bf2 tries to prevent a finishmigrate -> prelaunch transition by exiting at the beginning of the main_loop_should_exit() function if the state is already finishmigrate. As the finishmigrate state is set in the migration thread it can happen concurrently to the function. The migration thread and the function are normally protected by the iothread mutex and thus the state should no evolve between the start of the function and its end. Unfortunately during the function life the lock is released by pause_all_vcpus() just before the point we need to be sure we are not in finishmigrate state and if the migration thread is waiting for the lock it will take the opportunity to change the state to finishmigrate. The only way to be sure we are not in the finishmigrate state when we need is to check the state after the pause_all_vcpus() function. Fixes: 1bd71dce4bf2 ("runstate: ignore exit request in finish migrate state") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit ddad81bd28de665475a87693a93e6cf5d6fd8bab) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:45:29 UTC
f3ef988 Jeff Kubascik 17 January 2020, 14:09:31 UTC target/arm: Return correct IL bit in merge_syn_data_abort The IL bit is set for 32-bit instructions, thus passing false with the is_16bit parameter to syn_data_abort_with_iss() makes a syn mask that always has the IL bit set. Pass is_16bit as true to make the initial syn mask have IL=0, so that the final IL value comes from or'ing template_syn. Cc: qemu-stable@nongnu.org Fixes: aaa1f954d4ca ("target-arm: A64: Create Instruction Syndromes for Data Aborts") Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200117004618.2742-2-richard.henderson@linaro.org [rth: Extracted this as a self-contained bug fix from a larger patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 30d544839e278dc76017b9a42990c41e84a34377) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:45:24 UTC
e8a2860 Laurent Vivier 07 January 2020, 16:34:37 UTC migration-test: ppc64: fix FORTH test program Commit e51e711b1bef has moved the initialization of start_address and end_address after the definition of the command line argument, where the nvramrc is initialized, and thus the loop is between 0 and 0 rather than 1 MiB and 100 MiB. It doesn't affect the result of the test if all the tests are run in sequence because the two first tests don't run the loop, so the values are correctly initialized when we actually need them. But it hangs when we ask to run only one test, for instance: QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 \ tests/migration-test -m=quick -p /ppc64/migration/validate_uuid_error Fixes: e51e711b1bef ("tests/migration: Add migration-test header file") Cc: wei@redhat.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20200107163437.52139-1-lvivier@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 16c5c6928ff53bd95e6504301ef6c285501531e7) Conflicts: tests/migration-test.c *drop context dep. on 68d95609 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:44:54 UTC
9a30621 Max Reitz 08 November 2019, 12:34:53 UTC blkdebug: Allow taking/unsharing permissions Sometimes it is useful to be able to add a node to the block graph that takes or unshare a certain set of permissions for debugging purposes. This patch adds this capability to blkdebug. (Note that you cannot make blkdebug release or share permissions that it needs to take or cannot share, because this might result in assertion failures in the block layer. But if the blkdebug node has no parents, it will not take any permissions and share everything by default, so you can then freely choose what permissions to take and share.) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191108123455.39445-4-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 69c6449ff10fe4e3219e960549307096d5366bd0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:38:34 UTC
0972fbf Max Reitz 08 November 2019, 12:34:51 UTC block: Add bdrv_qapi_perm_to_blk_perm() We need some way to correlate QAPI BlockPermission values with BLK_PERM_* flags. We could: (1) have the same order in the QAPI definition as the the BLK_PERM_* flags are in LSb-first order. However, then there is no guarantee that they actually match (e.g. when someone modifies the QAPI schema without thinking of the BLK_PERM_* definitions). We could add static assertions, but these would break what’s good about this solution, namely its simplicity. (2) define the BLK_PERM_* flags based on the BlockPermission values. But this way whenever someone were to modify the QAPI order (perfectly sensible in theory), the BLK_PERM_* values would change. Because these values are used for file locking, this might break file locking between different qemu versions. Therefore, go the slightly more cumbersome way: Add a function to translate from the QAPI constants to the BLK_PERM_* flags. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191108123455.39445-2-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 7b1d9c4df0603fbc526226a9c5ef91118aa6c957) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:38:31 UTC
9b59fdf Simon Veith 20 December 2019, 14:03:00 UTC hw/arm/smmuv3: Report F_STE_FETCH fault address in correct word position The smmuv3_record_event() function that generates the F_STE_FETCH error uses the EVT_SET_ADDR macro to record the fetch address, placing it in 32-bit words 4 and 5. The correct position for this address is in words 6 and 7, per the SMMUv3 Architecture Specification. Update the function to use the EVT_SET_ADDR2 macro instead, which is the macro intended for writing to these words. ref. ARM IHI 0070C, section 7.3.4. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-7-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit b255cafb59578d16716186ed955717bc8f87bdb7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:38:26 UTC
ec3bd88 Simon Veith 20 December 2019, 14:03:00 UTC hw/arm/smmuv3: Use correct bit positions in EVT_SET_ADDR2 macro The bit offsets in the EVT_SET_ADDR2 macro do not match those specified in the ARM SMMUv3 Architecture Specification. In all events that use this macro, e.g. F_WALK_EABT, the faulting fetch address or IPA actually occupies the 32-bit words 6 and 7 in the event record contiguously, with the upper and lower unused bits clear due to alignment or maximum supported address bits. How many bits are clear depends on the individual event type. Update the macro to write to the correct words in the event record so that guest drivers can obtain accurate address information on events. ref. ARM IHI 0070C, sections 7.3.12 through 7.3.16. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-6-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a7f65ceb851af5a5b639c6e30801076d848db2c2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:38:22 UTC
65fad28 Simon Veith 20 December 2019, 14:03:00 UTC hw/arm/smmuv3: Align stream table base address to table size Per the specification, and as observed in hardware, the SMMUv3 aligns the SMMU_STRTAB_BASE address to the size of the table by masking out the respective least significant bits in the ADDR field. Apply this masking logic to our smmu_find_ste() lookup function per the specification. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-5-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 41678c33aac61261522b74f08595ccf2221a430a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:38:17 UTC
256ecc0 Simon Veith 20 December 2019, 14:03:00 UTC hw/arm/smmuv3: Check stream IDs against actual table LOG2SIZE When checking whether a stream ID is in range of the stream table, we have so far been only checking it against our implementation limit (SMMU_IDR1_SIDSIZE). However, the guest can program the STRTAB_BASE_CFG.LOG2SIZE field to a size that is smaller than this limit. Check the stream ID against this limit as well to match the hardware behavior of raising C_BAD_STREAMID events in case the limit is exceeded. Also, ensure that we do not go one entry beyond the end of the table by checking that its index is strictly smaller than the table size. ref. ARM IHI 0070C, section 6.3.24. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-4-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 05ff2fb80ce4ca85d8a39d48ff8156de739b4f51) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:37:56 UTC
606a6bf Simon Veith 20 December 2019, 14:03:00 UTC hw/arm/smmuv3: Correct SMMU_BASE_ADDR_MASK value There are two issues with the current value of SMMU_BASE_ADDR_MASK: - At the lower end, we are clearing bits [4:0]. Per the SMMUv3 spec, we should also be treating bit 5 as zero in the base address. - At the upper end, we are clearing bits [63:48]. Per the SMMUv3 spec, only bits [63:52] must be explicitly treated as zero. Update the SMMU_BASE_ADDR_MASK value to mask out bits [63:52] and [5:0]. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-3-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3293b9f514a413e019b7dbc9d543458075b4849e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:37:16 UTC
e8ae3a4 Simon Veith 20 December 2019, 14:03:00 UTC hw/arm/smmuv3: Apply address mask to linear strtab base address In the SMMU_STRTAB_BASE register, the stream table base address only occupies bits [51:6]. Other bits, such as RA (bit [62]), must be masked out to obtain the base address. The branch for 2-level stream tables correctly applies this mask by way of SMMU_BASE_ADDR_MASK, but the one for linear stream tables does not. Apply the missing mask in that case as well so that the correct stream base address is used by guests which configure a linear stream table. Linux guests are unaffected by this change because they choose a 2-level stream table layout for the QEMU SMMUv3, based on the size of its stream ID space. ref. ARM IHI 0070C, section 6.3.23. Signed-off-by: Simon Veith <sveith@amazon.de> Acked-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1576509312-13083-2-git-send-email-sveith@amazon.de Cc: Eric Auger <eric.auger@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Acked-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3d44c60500785f18bb469c9de0aeba7415c0f28f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:37:11 UTC
7e1bc51 Cameron Esfahani 10 December 2019, 21:27:54 UTC display/bochs-display: fix memory leak Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame. Fixes: 33ebad54056 Signed-off-by: Cameron Esfahani <dirty@apple.com> Message-Id: <d6c26e68db134c7b0c7ce8b61596ca2e65e01e12.1576013209.git.dirty@apple.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0d82411d0e38a0de7829f97d04406765c8d2210d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:37:06 UTC
8d151ab Cole Robinson 19 September 2019, 20:33:44 UTC vhost-user-gpu: Drop trailing json comma Trailing comma is not valid json: $ cat contrib/vhost-user-gpu/50-qemu-gpu.json.in | jq parse error: Expected another key-value pair at line 5, column 1 Signed-off-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 7f5dd2ac9f3504e2699f23e69bc3d8051b729832.1568925097.git.crobinso@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit ca26b032e5a0e8a190c763ce828a8740d24b9b65) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:37:02 UTC
6772bba Max Reitz 18 December 2019, 10:48:55 UTC iotests: Fix IMGOPTSSYNTAX for nbd There is no $SOCKDIR, only $SOCK_DIR. Fixes: f3923a72f199b2c63747a7032db74730546f55c6 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit eb4ea9aaa0051054b3c148ad8631be7510851681) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:36:47 UTC
45b65bf Robert Foley 18 November 2019, 21:15:23 UTC Fix double free issue in qemu_set_log_filename(). After freeing the logfilename, we set logfilename to NULL, in case of an error which returns without setting logfilename. Signed-off-by: Robert Foley <robert.foley@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20191118211528.3221-2-robert.foley@linaro.org> (cherry picked from commit 0f516ca4767042aec8716369d6d62436fa10593a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:36:43 UTC
aea7a50 Han Han 05 December 2019, 02:48:21 UTC Revert "qemu-options.hx: Update for reboot-timeout parameter" This reverts commit bbd9e6985ff342cbe15b9cb7eb30e842796fbbe8. In 20a1922032 we allowed reboot-timeout=-1 again, so update the doc accordingly. Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20191205024821.245435-1-hhan@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 8937a39da22e5d5689c516a2d4ce4f2bb6a378fc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:36:38 UTC
2f7597f Max Reitz 11 March 2020, 14:07:07 UTC iotests/026: Move v3-exclusive test to new file data_file does not work with v2, and we probably want 026 to keep working for v2 images. Thus, open a new file for v3-exclusive error path test cases. Fixes: 81311255f217859413c94f2cd9cebf2684bbda94 (“iotests/026: Test EIO on allocation in a data-file”) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200311140707.1243218-1-mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Tested-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit c264e5d2f9f5d73977eac8e5d084f727b3d07ea9) Conflicts: tests/qemu-iotests/group Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:35:23 UTC
f127d16 Finn Thain 04 March 2020, 03:23:05 UTC dp8393x: Mask EOL bit from descriptor addresses, take 2 A portion of a recent patch got lost due to a merge snafu. That patch is now commit 88f632fbb1 ("dp8393x: Mask EOL bit from descriptor addresses"). This patch restores the portion that got lost. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <alpine.LNX.2.22.394.2003041421280.12@nippy.intranet> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit a0cf4297d6b8d88047ab00c467f14aecf9c2a8eb) Conflicts: hw/net/dp8393x.c *drop context dep. on 19f70347 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:31:47 UTC
8622408 Marc-André Lureau 21 April 2020, 17:02:27 UTC slirp: update to fix CVE-2020-1983 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> (cherry picked from commit 7769c23774d1278f60b9e40d2c0b98784de6425f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:27:12 UTC
1343d33 Dr. David Alan Gilbert 21 November 2019, 16:56:45 UTC kvm: Reallocate dirty_bmap when we change a slot kvm_set_phys_mem can be called to reallocate a slot by something the guest does (e.g. writing to PAM and other chipset registers). This can happen in the middle of a migration, and if we're unlucky it can now happen between the split 'sync' and 'clear'; the clear asserts if there's no bmap to clear. Recreate the bmap whenever we change the slot, keeping the clear path happy. Typically this is triggered by the guest rebooting during a migrate. Corresponds to: https://bugzilla.redhat.com/show_bug.cgi?id=1772774 https://bugzilla.redhat.com/show_bug.cgi?id=1771032 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 9b3a31c745b61758aaa5466a3a9fc0526d409188) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:15:37 UTC
c436692 Prasad J Pandit 14 May 2020, 20:06:08 UTC es1370: check total frame count against current frame 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> 22 June 2020, 17:15:05 UTC
69a6048 Prasad J Pandit 04 June 2020, 09:08:30 UTC ati-vga: check mm_index before recursive call (CVE-2020-13800) 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> 22 June 2020, 17:15:00 UTC
01392ae BALATON Zoltan 06 April 2020, 20:34:26 UTC ati-vga: Fix checks in ati_2d_blt() to avoid crash In some corner cases (that never happen during normal operation but a malicious guest could program wrong values) pixman functions were called with parameters that result in a crash. Fix this and add more checks to disallow such cases. Reported-by: Ziming Zhang <ezrakiez@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200406204029.19559747D5D@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit ac2071c3791b67fc7af78b8ceb320c01ca1b5df7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:14:54 UTC
4e98c38 Felipe Franciosi 23 January 2020, 12:44:59 UTC iscsi: Cap block count from GET LBA STATUS (CVE-2020-1711) When querying an iSCSI server for the provisioning status of blocks (via GET LBA STATUS), Qemu only validates that the response descriptor zero's LBA matches the one requested. Given the SCSI spec allows servers to respond with the status of blocks beyond the end of the LUN, Qemu may have its heap corrupted by clearing/setting too many bits at the end of its allocmap for the LUN. A malicious guest in control of the iSCSI server could carefully program Qemu's heap (by selectively setting the bitmap) and then smash it. This limits the number of bits that iscsi_co_block_status() will try to update in the allocmap so it can't overflow the bitmap. Fixes: CVE-2020-1711 Cc: qemu-stable@nongnu.org Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Peter Turschmid <peter.turschm@nutanix.com> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 693fd2acdf14dd86c0bf852610f1c2cca80a74dc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:14:48 UTC
54bcaf0 Vitaly Kuznetsov 31 March 2020, 16:27:52 UTC target/i386: do not set unsupported VMX secondary execution controls Commit 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") added a workaround for KVM pre-dating commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm KVM_GET_MSRS") which wasn't setting certain available controls. The workaround uses generic CPUID feature bits to set missing VMX controls. It was found that in some cases it is possible to observe hosts which have certain CPUID features but lack the corresponding VMX control. In particular, it was reported that Azure VMs have RDSEED but lack VMX_SECONDARY_EXEC_RDSEED_EXITING; attempts to enable this feature bit result in QEMU abort. Resolve the issue but not applying the workaround when we don't have to. As there is no good way to find out if KVM has the fix itself, use 95c5c7c77c ("KVM: nVMX: list VMX MSRs in KVM_GET_MSR_INDEX_LIST") instead as these [are supposed to] come together. Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200331162752.1209928-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4a910e1f6ab4155ec8b24c49b2585cc486916985) Conflicts: target/i386/kvm.c *drop context dep. on 6702514814c Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:14:11 UTC
e727aa1 ShihPo Hung 15 January 2020, 06:17:33 UTC target/riscv: update mstatus.SD when FS is set dirty remove the check becuase SD bit should summarize FS and XS fields unconditionally. Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit 82f014671cf057de51c4a577c9e2ad637dcec6f9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:09:02 UTC
690e300 ShihPo Hung 15 January 2020, 06:17:32 UTC target/riscv: fsd/fsw doesn't dirty FP state Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit a59796eb6d59bbd74ce28ddbddb1b83e60674e96) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:08:58 UTC
a918ea2 ShihPo Hung 15 January 2020, 06:17:31 UTC target/riscv: Fix tb->flags FS status It was found that running libquantum on riscv-linux qemu produced an incorrect result. After investigation, FP registers are not saved during context switch due to incorrect mstatus.FS. In current implementation tb->flags merges all non-disabled state to dirty. This means the code in mark_fs_dirty in translate.c that handles initial and clean states is unreachable. This patch fixes it and is successfully tested with: libquantum Thanks to Richard for pointing out the actual bug. v3: remove the redundant condition v2: root cause FS problem Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit 613fa160e19abe8e1fe44423fcfa8ec73d3d48e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:08:54 UTC
c1cad76 Yiting Wang 03 January 2020, 03:53:42 UTC riscv: Set xPIE to 1 after xRET When executing an xRET instruction, supposing xPP holds the value y, xIE is set to xPIE; the privilege mode is changed to y; xPIE is set to 1. But QEMU sets xPIE to 0 incorrectly. Signed-off-by: Yiting Wang <yiting.wang@windriver.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit a37f21c27d3e2342c2080aafd4cfe7e949612428) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:08:50 UTC
a6e44ee Pan Nengyuan 10 December 2019, 07:14:37 UTC riscv/sifive_u: fix a memory leak in soc_realize() Fix a minor memory leak in riscv_sifive_u_soc_realize() Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> (cherry picked from commit bb8136df698bd565ee4f6c18d26c50dee320bfe4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:08:46 UTC
3729ff3 Cole Robinson 13 November 2019, 21:09:35 UTC tests: fix modules-test 'duplicate test case' error ./configure --enable-sdl --audio-drv-list=sdl --enable-modules Will generate two identical test names: /$arch/module/load/sdl Which generates an error like: (tests/modules-test:23814): GLib-ERROR **: 18:23:06.359: duplicate test case path: /aarch64//module/load/sdl Add the subsystem prefix in the name as well, so instead we get: /$arch/module/load/audio-sdl /$arch/module/load/ui-sdl Signed-off-by: Cole Robinson <crobinso@redhat.com> Message-Id: <d64c9aa098cc6e5c0b638438c4959eddfa7e24e2.1573679311.git.crobinso@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit eca3a945234a5f0a499860dd11df64b5f1a2e0a5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 22 June 2020, 17:07:45 UTC
2367c72 Stefano Stabellini 21 May 2020, 19:26:26 UTC xen/9pfs: yield when there isn't enough room on the ring 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> 16 June 2020, 22:21:43 UTC
0c6499f Dan Robertson 25 May 2020, 08:38:03 UTC 9pfs: include linux/limits.h for XATTR_SIZE_MAX 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> 16 June 2020, 22:21:38 UTC
17216bc Omar Sandoval 14 May 2020, 06:06:43 UTC 9pfs: local: ignore O_NOATIME if we don't have permissions 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> 16 June 2020, 22:21:33 UTC
410252f Greg Kurz 10 March 2020, 15:12:49 UTC 9p/proxy: Fix export_flags The common fsdev options are set by qemu_fsdev_add() before it calls the backend specific option parsing code. In the case of "proxy" this means "writeout" or "readonly" were simply ignored. This has been broken from the beginning. Reported-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158349633705.1237488.8895481990204796135.stgit@bahia.lan> (cherry picked from commit 659f1953281bcfa5ac217e42877d7d3c32eeea38) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 16 June 2020, 22:21:28 UTC
603cda2 Pan Nengyuan 17 January 2020, 06:09:26 UTC virtio-9p-device: fix memleak in virtio_9p_device_unrealize v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624) /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7) /mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209 #4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6) /mnt/sdb/qemu/hw/virtio/virtio.c:3504 #5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37) /mnt/sdb/qemu/hw/core/qdev.c:876 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117060927.51996-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Acked-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 9580d60e66d1543a0d79265c0085ee09b8782987) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 16 June 2020, 22:21:23 UTC
03afe9c Daniel Henrique Barboza 20 January 2020, 14:11:39 UTC 9p: local: always return -1 on error in local_unlinkat_common local_unlinkat_common() is supposed to always return -1 on error. This is being done by jumps to the 'err_out' label, which is a 'return ret' call, and 'ret' is initialized with -1. Unfortunately there is a condition in which the function will return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret' will be 0 when reaching map_dirfd = openat_dir(...) And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out' jump will execute 'return ret', when ret is still set to zero at that point. This patch fixes it by changing all 'err_out' labels by 'return -1' calls, ensuring that the function will always return -1 on error conditions. 'ret' can be left unintialized since it's now being used just to store the result of 'unlinkat' calls. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> [groug: changed prefix in title to be "9p: local:"] Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 846cf408a4c8055063f4a5a71ccf7ed030cdad30) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 16 June 2020, 22:21:18 UTC
18f6b13 Jiajun Chen 20 January 2020, 14:11:39 UTC 9pfs: local: Fix possible memory leak in local_link() There is a possible memory leak while local_link return -1 without free odirpath and oname. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com> Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 841b8d099c462cd4282c4ced8c2a6512899fd8d9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 16 June 2020, 22:21:13 UTC
6c75ddf Eric Blake 08 June 2020, 18:26:38 UTC block: Call attention to truncation of long NBD exports 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> 16 June 2020, 01:29:36 UTC
d6d45d9 David Hildenbrand 20 May 2020, 10:04:39 UTC virtio-balloon: unref the iothread when unrealizing 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> 16 June 2020, 01:25:29 UTC
2a7c80d David Hildenbrand 20 May 2020, 10:04:38 UTC virtio-balloon: fix free page hinting check on unrealize 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> 16 June 2020, 01:25:21 UTC
e27f334 David Hildenbrand 20 May 2020, 10:04:37 UTC virtio-balloon: fix free page hinting without an iothread 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> 16 June 2020, 01:25:12 UTC
0c1d805 Eric Blake 08 June 2020, 18:26:37 UTC nbd/server: Avoid long error message assertions CVE-2020-10761 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> 16 June 2020, 01:22:05 UTC
252d614 Thomas Huth 18 May 2020, 07:43:52 UTC net: Do not include a newline in the id of -nic devices 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> 16 June 2020, 01:21:02 UTC
dad6d5e Greg Kurz 25 May 2020, 08:38:03 UTC 9p: Lock directory streams with a CoMutex 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> 10 June 2020, 02:38:35 UTC
ad56aec Raphael Pour 15 May 2020, 06:36:07 UTC qemu-nbd: Close inherited stderr 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> 10 June 2020, 02:34:47 UTC
d5691a6 Richard Henderson 13 May 2020, 16:32:43 UTC target/arm: Clear tail in gvec_fmul_idx_*, gvec_fmla_idx_* 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> 10 June 2020, 02:34:17 UTC
34c78a4 Igor Mammedov 30 April 2020, 15:46:06 UTC hostmem: don't use mbind() if host-nodes is empty 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> 10 June 2020, 02:25:14 UTC
8d127b4 Nicholas Piggin 14 April 2020, 11:11:31 UTC target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts 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> (cherry picked from commit 5ed195065cc6895f61b9d59bfa0a0536ed5ed51e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 10 June 2020, 02:10:26 UTC
ea1518b Philippe Mathieu-Daudé 23 March 2020, 11:29:41 UTC vhost-user-gpu: Release memory returned by vu_queue_pop() with free() 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> (cherry picked from commit 4ff97121a3ee631971aadc87e3d4e7fb66f15aa8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 10 June 2020, 02:10:03 UTC
c5feb39 Anthony PERARD 06 April 2020, 14:02:17 UTC xen-block: Fix double qlist remove and request leak Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on remove") revealed that a request was removed twice from a list, once in xen_block_finish_request() and a second time in xen_block_release_request() when both function are called from xen_block_complete_aio(). But also, the `requests_inflight' counter is decreased twice, and thus became negative. This is a bug that was introduced in bfd0d6366043 ("xen-block: improve response latency"), where a `finished' list was removed. That commit also introduced a leak of request in xen_block_do_aio(). That function calls xen_block_finish_request() but the request is never released after that. To fix both issue, we do two changes: - we squash finish_request() and release_request() together as we want to remove a request from 'inflight' list to add it to 'freelist'. - before releasing a request, we need to let the other end know the result, thus we should call xen_block_send_response() before releasing a request. The first change fixes the double QLIST_REMOVE() as we remove the extra call. The second change makes the leak go away because if we want to call finish_request(), we need to call a function that does all of finish, send response, and release. Fixes: bfd0d6366043 ("xen-block: improve response latency") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200406140217.1441858-1-anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org> [mreitz: Amended commit message as per Paul's suggestions] Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 36d883ba0de8a281072ded2b51e0a711fd002139) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 10 June 2020, 02:09:42 UTC
25fcaed Peter Maydell 24 March 2020, 17:36:30 UTC dump: Fix writing of ELF section In write_elf_section() we set the 'shdr' pointer to point to local structures shdr32 or shdr64, which we fill in to be written out to the ELF dump. Unfortunately the address we pass to fd_write_vmcore() has a spurious '&' operator, so instead of writing out the section header we write out the literal pointer value followed by whatever is on the stack after the 'shdr' local variable. Pass the correct address into fd_write_vmcore(). Spotted by Coverity: CID 1421970. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200324173630.12221-1-peter.maydell@linaro.org (cherry picked from commit 174d2d6856bf435f4f58e9303ba30dd0e1279d3f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 10 June 2020, 02:09:12 UTC
aabd9dd Richard Henderson 29 March 2020, 01:16:10 UTC tcg/i386: Fix INDEX_op_dup2_vec We were only constructing the 64-bit element, and not replicating the 64-bit element across the rest of the vector. Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e20cb81d9c5a3d0f9c08f3642728a210a1c162c9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 10 June 2020, 02:01:38 UTC
33be7aa Peter Maydell 26 March 2020, 10:53:49 UTC hw/i386/amd_iommu.c: Fix corruption of log events passed to guest In the function amdvi_log_event(), we write an event log buffer entry into guest ram, whose contents are passed to the function via the "uint64_t *evt" argument. Unfortunately, a spurious '&' in the call to dma_memory_write() meant that instead of writing the event to the guest we would write the literal value of the pointer, plus whatever was in the following 8 bytes on the stack. This error was spotted by Coverity. Fix the bug by removing the '&'. Fixes: CID 1421945 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200326105349.24588-1-peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 32a2d6b1f6b4405f0fc20c031e61d5d48e3d9cd1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 10 June 2020, 02:00:52 UTC
8f5728c Stefan Hajnoczi 23 March 2020, 11:04:08 UTC qemu-ga: document vsock-listen in the man page Although qemu-ga has supported vsock since 2016 it was not documented on the man page. Also add the socket address representation to the qga --help output. Fixes: 586ef5dee77180fc32e33bc08051600030630239 ("qga: add vsock-listen method") Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit 7b46aadbbfb7b06cd45a3b113b1f7c003c68f603) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 04 June 2020, 01:14:55 UTC
e353161 Eric Blake 20 March 2020, 15:05:07 UTC qga: Fix undefined C behavior The QAPI struct GuestFileWhence has a comment about how we are exploiting equivalent values between two different integer types shared in a union. But C says behavior is undefined on assignments to overlapping storage when the two types are not the same width, and indeed, 'int64_t value' and 'enum QGASeek name' are very likely to be different in width. Utilize a temporary variable to fix things. Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 0b4b49387 Fixes: Coverity CID 1421990 Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit a23f38a72921fa915536a981a4f8a9134512f120) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 04 June 2020, 01:14:36 UTC
4996bd7 Basil Salman 11 March 2020, 17:04:17 UTC qga-win: prevent crash when executing guest-file-read with large count guest-file-read command is currently implemented to read from a file handle count number of bytes. when executed with a very large count number qemu-ga crashes. after some digging turns out that qemu-ga crashes after trying to allocate a buffer large enough to save the data read in it, the buffer was allocated using g_malloc0 which is not fail safe, and results a crash in case of failure. g_malloc0 was replaced with g_try_malloc0() which returns NULL on failure, A check was added for that case in order to prevent qemu-ga from crashing and to send a response to the qemu-ga client accordingly. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1594054 Signed-off-by: Basil Salman <basil@daynix.com> Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit 807e2b6fce022707418bc8f61c069d91c613b3d2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 04 June 2020, 01:13:51 UTC
3c3e165 Sameeh Jubran 11 March 2020, 17:04:16 UTC qga-win: Handle VSS_E_PROVIDER_ALREADY_REGISTERED error This patch handles the case where VSS Provider is already registered, where in such case qga uninstalls the provider and registers it again. Signed-off-by: Sameeh Jubran <sjubran@redhat.com> Signed-off-by: Basil Salman <basil@daynix.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit b2413df83348acf371c03bced9a3845bba883ed5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 04 June 2020, 01:13:46 UTC
7cc217b Basil Salman 11 March 2020, 17:04:15 UTC qga: Installer: Wait for installation to finish Installation might fail if we don't wait for the provider unregisteration process to finish. Signed-off-by: Sameeh Jubran <sjubran@redhat.com> Signed-off-by: Basil Salman <basil@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit bb1ce44b15f159b67fafc5f4b285bbf20a1961e9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 04 June 2020, 01:13:38 UTC
219362f Cornelia Huck 18 March 2020, 09:39:19 UTC compat: disable edid on correct virtio-gpu device Commit bb15791166c1 ("compat: disable edid on virtio-gpu base device") tried to disable 'edid' on the virtio-gpu base device. However, that device is not 'virtio-gpu', but 'virtio-gpu-device'. Fix it. Fixes: bb15791166c1 ("compat: disable edid on virtio-gpu base device") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Tested-by: Lukáš Doktor <ldoktor@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20200318093919.24942-1-cohuck@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 02501fc39381c4dabaf6becdd12c2a4754c3847c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> 04 June 2020, 01:10:27 UTC
back to top