[Qemu-commits] [qemu/qemu] 968a6a: util/vfio-helpers: Use g_file_read_link()

[Alex Bennée]

  Branch: refs/heads/staging-7.2
  Home:   https://github.com/qemu/qemu
  Commit: 968a6aff6b29335607b2eefbbd08d9adcef399a6
      
https://github.com/qemu/qemu/commit/968a6aff6b29335607b2eefbbd08d9adcef399a6
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2023-05-26 (Fri, 26 May 2023)

  Changed paths:
    M util/vfio-helpers.c

  Log Message:
  -----------
  util/vfio-helpers: Use g_file_read_link()

When _FORTIFY_SOURCE=2, glibc version is 2.35, and GCC version is
12.1.0, the compiler complains as follows:

In file included from /usr/include/features.h:490,
                 from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdint.h:26,
                 from 
/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/include/stdint.h:9,
                 from /home/alarm/q/var/qemu/include/qemu/osdep.h:94,
                 from ../util/vfio-helpers.c:13:
In function 'readlink',
    inlined from 'sysfs_find_group_file' at ../util/vfio-helpers.c:116:9,
    inlined from 'qemu_vfio_init_pci' at ../util/vfio-helpers.c:326:18,
    inlined from 'qemu_vfio_open_pci' at ../util/vfio-helpers.c:517:9:
/usr/include/bits/unistd.h:119:10: error: argument 2 is null but the 
corresponding size argument 3 value is 4095 [-Werror=nonnull]
  119 |   return __glibc_fortify (readlink, __len, sizeof (char),
      |          ^~~~~~~~~~~~~~~

This error implies the allocated buffer can be NULL. Use
g_file_read_link(), which allocates buffer automatically to avoid the
error.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit dbdea0dbfe2cef9ef6c752e9077e4fc98724194c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: b02de040ff96f7a23585ac6981d0b34ece5f39d2
      
https://github.com/qemu/qemu/commit/b02de040ff96f7a23585ac6981d0b34ece5f39d2
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2023-05-26 (Fri, 26 May 2023)

  Changed paths:
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  usb/ohci: Set pad to 0 after frame update

When the OHCI controller's framenumber is incremented, HccaPad1 register
should be set to zero (Ref OHCI Spec 4.4)

ReactOS uses hccaPad1 to determine if the OHCI hardware is running,
consequently it fails this check in current qemu master.

Signed-off-by: Ryan Wendland <wendland@live.com.au>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1048
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6301460ce9f59885e8feb65185bcfb6b128c8eff)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: ae4b9d82e277eae04b4d5eceb7e050be79b694e4
      
https://github.com/qemu/qemu/commit/ae4b9d82e277eae04b4d5eceb7e050be79b694e4
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2023-05-26 (Fri, 26 May 2023)

  Changed paths:
    M hw/scsi/lsi53c895a.c
    M tests/qtest/fuzz-lsi53c895a-test.c

  Log Message:
  -----------
  hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller 
(CVE-2023-0330)

We cannot use the generic reentrancy guard in the LSI code, so
we have to manually prevent endless reentrancy here. The problematic
lsi_execute_script() function has already a way to detect whether
too many instructions have been executed - we just have to slightly
change the logic here that it also takes into account if the function
has been called too often in a reentrant way.

The code in fuzz-lsi53c895a-test.c has been taken from an earlier
patch by Mauro Matteo Cascella.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1563
Message-Id: <20230522091011.1082574-1-thuth@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit b987718bbb1d0eabf95499b976212dd5f0120d75)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 3e2e462487223d10d50cd2f071ba5d9508556ae6
      
https://github.com/qemu/qemu/commit/3e2e462487223d10d50cd2f071ba5d9508556ae6
  Author: Igor Mammedov <imammedo@redhat.com>
  Date:   2023-05-26 (Fri, 26 May 2023)

  Changed paths:
    M hw/core/machine.c

  Log Message:
  -----------
  machine: do not crash if default RAM backend name has been stolen

QEMU aborts when default RAM backend should be used (i.e. no
explicit '-machine memory-backend=' specified) but user
has created an object which 'id' equals to default RAM backend
name used by board.

 $QEMU -machine pc \
       -object memory-backend-ram,id=pc.ram,size=4294967296

 Actual results:
 QEMU 7.2.0 monitor - type 'help' for more information
 (qemu) Unexpected error in object_property_try_add() at ../qom/object.c:1239:
 qemu-kvm: attempt to add duplicate property 'pc.ram' to object (type 
'container')
 Aborted (core dumped)

Instead of abort, check for the conflicting 'id' and exit with
an error, suggesting how to remedy the issue.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2207886
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20230522131717.3780533-1-imammedo@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit a37531f2381c4e294e48b1417089474128388b44)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/774d5a90b25d...3e2e46248722