[Qemu-commits] [qemu/qemu] 6f7b9f: vnc: avoid underflow when accessing user-provided ...

[Alex Bennée]

  Branch: refs/heads/stable-8.0-staging
  Home:   https://github.com/qemu/qemu
  Commit: 6f7b9f7b6fdf8486e2f17fe3ddaeafe598c3b3a6
      
https://github.com/qemu/qemu/commit/6f7b9f7b6fdf8486e2f17fe3ddaeafe598c3b3a6
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2023-04-26 (Wed, 26 Apr 2023)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  vnc: avoid underflow when accessing user-provided address

If hostlen is zero, there is a possibility that addrstr[hostlen - 1]
underflows and, if a closing bracked is there, hostlen - 2 is passed
to g_strndup() on the next line.  If websocket==false then
addrstr[0] would be a colon, but if websocket==true this could in
principle happen.

Fix it by checking hostlen.

Reported by Coverity.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 3f9c41c5df9617510d8533cf6588172efb3df34b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 3ed99d232c1173aff3806908e29f29b30af7d58e
      
https://github.com/qemu/qemu/commit/3ed99d232c1173aff3806908e29f29b30af7d58e
  Author: Yang Zhong <yang.zhong@linux.intel.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  target/i386: Change wrong XFRM value in SGX CPUID leaf

The previous patch wrongly replaced FEAT_XSAVE_XCR0_{LO|HI} with
FEAT_XSAVE_XSS_{LO|HI} in CPUID(EAX=12,ECX=1):{ECX,EDX}.  As a result,
SGX enclaves only supported SSE and x87 feature (xfrm=0x3).

Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features")
Signed-off-by: Yang Zhong <yang.zhong@linux.intel.com>
Reviewed-by: Yang Weijiang <weijiang.yang@intel.com>
Reviewed-by: Kai Huang <kai.huang@intel.com>
Message-Id: <20230406064041.420039-1-yang.zhong@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 72497cff896fecf74306ed33626c30e43633cdd6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: ac7f07ebc8facf0c96905db8b6b6a453b284edfb
      
https://github.com/qemu/qemu/commit/ac7f07ebc8facf0c96905db8b6b6a453b284edfb
  Author: Axel Heider <axel.heider@hensoldt.net>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M hw/timer/imx_epit.c

  Log Message:
  -----------
  hw/timer/imx_epit: don't shadow variable

Fix issue reported by Coverity.

Signed-off-by: Axel Heider <axel.heider@hensoldt.net>
Message-id: 168070611775.20412.2883242077302841473-1@git.sr.ht
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 542fd43d79327dabe62e49ff584ca60b6184923a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 134a1a33207723bf0adc35e2272b6a147484d4b8
      
https://github.com/qemu/qemu/commit/134a1a33207723bf0adc35e2272b6a147484d4b8
  Author: Axel Heider <axel.heider@hensoldt.net>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M hw/timer/imx_epit.c

  Log Message:
  -----------
  hw/timer/imx_epit: fix limit check

Fix the limit check. If the limit is less than the compare value,
the timer can never reach this value, thus it will never fire.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1491
Signed-off-by: Axel Heider <axel.heider@hensoldt.net>
Message-id: 168070611775.20412.2883242077302841473-2@git.sr.ht
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 25d758175dfbfd53e02b4a52ac68cbd6eb05f648)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: f52121827c0ecd218f55c8ed36e8ce5063015097
      
https://github.com/qemu/qemu/commit/f52121827c0ecd218f55c8ed36e8ce5063015097
  Author: Carlos López <clopez@suse.de>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M hw/s390x/virtio-ccw.c
    M hw/virtio/virtio-mmio.c
    M hw/virtio/virtio-pci.c
    M hw/virtio/virtio.c
    M include/hw/virtio/virtio.h

  Log Message:
  -----------
  virtio: refresh vring region cache after updating a virtqueue size

When a virtqueue size is changed by the guest via
virtio_queue_set_num(), its region cache is not automatically updated.
If the size was increased, this could lead to accessing the cache out
of bounds. For example, in vring_get_used_event():

    static inline uint16_t vring_get_used_event(VirtQueue *vq)
    {
        return vring_avail_ring(vq, vq->vring.num);
    }

    static inline uint16_t vring_avail_ring(VirtQueue *vq, int i)
    {
        VRingMemoryRegionCaches *caches = vring_get_region_caches(vq);
        hwaddr pa = offsetof(VRingAvail, ring[i]);

        if (!caches) {
            return 0;
        }

        return virtio_lduw_phys_cached(vq->vdev, &caches->avail, pa);
    }

vq->vring.num will be greater than caches->avail.len, which will
trigger a failed assertion down the call path of
virtio_lduw_phys_cached().

Fix this by calling virtio_init_region_cache() after
virtio_queue_set_num() if we are not already calling
virtio_queue_set_rings(). In the legacy path this is already done by
virtio_queue_update_rings().

Signed-off-by: Carlos López <clopez@suse.de>
Message-Id: <20230317002749.27379-1-clopez@suse.de>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit f0d634ea1964ccce317818c44fe299e71007e64d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 76326210e43991e9fb678ec05e06463c99794611
      
https://github.com/qemu/qemu/commit/76326210e43991e9fb678ec05e06463c99794611
  Author: Igor Mammedov <imammedo@redhat.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M hw/acpi/pcihp.c

  Log Message:
  -----------
  acpi: pcihp: allow repeating hot-unplug requests

with Q35 using ACPI PCI hotplug by default, user's request to unplug
device is ignored when it's issued before guest OS has been booted.
And any additional attempt to request device hot-unplug afterwards
results in following error:

  "Device XYZ is already in the process of unplug"

arguably it can be considered as a regression introduced by [2],
before which it was possible to issue unplug request multiple
times.

Accept new uplug requests after timeout (1ms). This brings ACPI PCI
hotplug on par with native PCIe unplug behavior [1] and allows user
to repeat unplug requests at propper times.
Set expire timeout to arbitrary 1msec so user won't be able to
flood guest with SCI interrupts by calling device_del in tight loop.

PS:
ACPI spec doesn't mandate what OSPM can do with GPEx.status
bits set before it's booted => it's impl. depended.
Status bits may be retained (I tested with one Windows version)
or cleared (Linux since 2.6 kernel times) during guest's ACPI
subsystem initialization.
Clearing status bits (though not wrong per se) hides the unplug
event from guest, and it's upto user to repeat device_del later
when guest is able to handle unplug requests.

1) 18416c62e3 ("pcie: expire pending delete")
2)
Fixes: cce8944cc9ef ("qdev-monitor: Forbid repeated device_del")
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
CC: mst@redhat.com
CC: anisinha@redhat.com
CC: jusual@redhat.com
CC: kraxel@redhat.com
Message-Id: <20230418090449.2155757-1-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Ani Sinha <anisinha@redhat.com>
(cherry picked from commit 0f689cf5ada4d5df5ab95c7f7aa9fc221afa855d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 747c801f51251818bfd45759896bfad4749bf98b
      
https://github.com/qemu/qemu/commit/747c801f51251818bfd45759896bfad4749bf98b
  Author: Wang Liang <wangliangzz@inspur.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M block/monitor/block-hmp-cmds.c

  Log Message:
  -----------
  block/monitor: Fix crash when executing HMP commit

hmp_commit() calls blk_is_available() from a non-coroutine context (and
in the main loop). blk_is_available() is a co_wrapper_mixed_bdrv_rdlock
function, and in the non-coroutine context it calls AIO_WAIT_WHILE(),
which crashes if the aio_context lock is not taken before.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1615
Signed-off-by: Wang Liang <wangliangzz@inspur.com>
Message-Id: <20230424103902.45265-1-wangliangzz@126.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 8c1e8fb2e7fc2cbeb57703e143965a4cd3ad301a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/6f7b9f7b6fdf%5E...747c801f5125