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

[Alex Bennée]

  Branch: refs/heads/stable-7.2-staging
  Home:   https://github.com/qemu/qemu
  Commit: bfc532703f3c4f8d2744748c440ca36ce9798ccb
      
https://github.com/qemu/qemu/commit/bfc532703f3c4f8d2744748c440ca36ce9798ccb
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2023-04-27 (Thu, 27 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: 84d5232d9d16541e803ad572ef48e6008677f8ff
      
https://github.com/qemu/qemu/commit/84d5232d9d16541e803ad572ef48e6008677f8ff
  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: d74a8cb440796243b0c9b29b05cc30d6b907677d
      
https://github.com/qemu/qemu/commit/d74a8cb440796243b0c9b29b05cc30d6b907677d
  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>
(cherry picked from commit f52121827c0ecd218f55c8ed36e8ce5063015097)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 59d620e252736ffc23e806c60143004a5dbfb193
      
https://github.com/qemu/qemu/commit/59d620e252736ffc23e806c60143004a5dbfb193
  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>
(cherry picked from commit 76326210e43991e9fb678ec05e06463c99794611)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/bfc532703f3c%5E...59d620e25273