Branch: refs/heads/staging-7.2
Home: https://github.com/qemu/qemu
Commit: 859759ee3995a3130855732860536588c0f33668
https://github.com/qemu/qemu/commit/859759ee3995a3130855732860536588c0f33668
Author: Stefan Hajnoczi <[email protected]>
Date: 2023-05-28 (Sun, 28 May 2023)
Changed paths:
M hw/net/rtl8139.c
Log Message:
-----------
rtl8139: fix large_send_mss divide-by-zero
If the driver sets large_send_mss to 0 then a divide-by-zero occurs.
Even if the division wasn't a problem, the for loop that emits MSS-sized
packets would never terminate.
Solve these issues by skipping offloading when large_send_mss=0.
This issue was found by OSS-Fuzz as part of Alexander Bulekov's device
fuzzing work. The reproducer is:
$ cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \
512M,slots=1,maxmem=0xffff000000000000 -machine q35 -nodefaults -device \
rtl8139,netdev=net0 -netdev user,id=net0 -device \
pc-dimm,id=nv1,memdev=mem1,addr=0xb800a64602800000 -object \
memory-backend-ram,id=mem1,size=2M -qtest stdio
outl 0xcf8 0x80000814
outl 0xcfc 0xe0000000
outl 0xcf8 0x80000804
outw 0xcfc 0x06
write 0xe0000037 0x1 0x04
write 0xe00000e0 0x2 0x01
write 0x1 0x1 0x04
write 0x3 0x1 0x98
write 0xa 0x1 0x8c
write 0xb 0x1 0x02
write 0xc 0x1 0x46
write 0xd 0x1 0xa6
write 0xf 0x1 0xb8
write 0xb800a646028c000c 0x1 0x08
write 0xb800a646028c000e 0x1 0x47
write 0xb800a646028c0010 0x1 0x02
write 0xb800a646028c0017 0x1 0x06
write 0xb800a646028c0036 0x1 0x80
write 0xe00000d9 0x1 0x40
EOF
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/1582
Closes: https://gitlab.com/qemu-project/qemu/-/issues/1582
Cc: [email protected]
Cc: Peter Maydell <[email protected]>
Fixes: 6d71357a3b65 ("rtl8139: honor large send MSS value")
Reported-by: Alexander Bulekov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Alexander Bulekov <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 792676c165159c11412346870fd58fd243ab2166)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 12f0e6175808505f9c458a6c03967a49e6980159
https://github.com/qemu/qemu/commit/12f0e6175808505f9c458a6c03967a49e6980159
Author: Akihiko Odaki <[email protected]>
Date: 2023-05-28 (Sun, 28 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 <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit dbdea0dbfe2cef9ef6c752e9077e4fc98724194c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 49d5fc4cfc420145aa203d14345bd1da48df1c9b
https://github.com/qemu/qemu/commit/49d5fc4cfc420145aa203d14345bd1da48df1c9b
Author: Paolo Bonzini <[email protected]>
Date: 2023-05-28 (Sun, 28 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 <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1048
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 6301460ce9f59885e8feb65185bcfb6b128c8eff)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9fe6e8139dc268f9916b8b7ce3ed9586c5354d11
https://github.com/qemu/qemu/commit/9fe6e8139dc268f9916b8b7ce3ed9586c5354d11
Author: Thomas Huth <[email protected]>
Date: 2023-05-28 (Sun, 28 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: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Alexander Bulekov <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit b987718bbb1d0eabf95499b976212dd5f0120d75)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9d52aaa92bd8b301e918dc5055041932ee1e0371
https://github.com/qemu/qemu/commit/9d52aaa92bd8b301e918dc5055041932ee1e0371
Author: Igor Mammedov <[email protected]>
Date: 2023-05-28 (Sun, 28 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 <[email protected]>
Message-Id: <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Shaoqin Huang <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit a37531f2381c4e294e48b1417089474128388b44)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/3e2e46248722...9d52aaa92bd8
