[Qemu-commits] [qemu/qemu] 668aee: util/vfio-helpers: Use g_file_read_link()

[Alex Bennée]

  Branch: refs/heads/staging-8.0
  Home:   https://github.com/qemu/qemu
  Commit: 668aeea0ecb651ce3d8e42cc4fa59e29dd9f009e
      
https://github.com/qemu/qemu/commit/668aeea0ecb651ce3d8e42cc4fa59e29dd9f009e
  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: 9d622451fdf9693a2265d5c04b041627f81d8c1d
      
https://github.com/qemu/qemu/commit/9d622451fdf9693a2265d5c04b041627f81d8c1d
  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: e49884a90987744ddb54b2fadc770633eb6a4d62
      
https://github.com/qemu/qemu/commit/e49884a90987744ddb54b2fadc770633eb6a4d62
  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: 134253a4fe9a1307308f2908424c354f989ee52f
      
https://github.com/qemu/qemu/commit/134253a4fe9a1307308f2908424c354f989ee52f
  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/fae9449998e7...134253a4fe9a