qemu/qemu.git, branch v7.2.15

Update version for 7.2.15 release

2024-11-20T21:11:28+00:00

Signed-off-by: Michael Tokarev

usb-hub: Fix handling port power control messages

2024-11-18T16:37:45+00:00

The ClearPortFeature control message fails for PORT_POWER because there is no break; at the end of the case statement, causing it to fall through to the failure handler. Add the missing break; to solve the problem. Fixes: 1cc403eb21 ("usb-hub: emulate per port power switching") Signed-off-by: Guenter Roeck Reviewed-by: Philippe Mathieu-Daudé Message-ID: <20241112170152.217664-11-linux@roeck-us.net> Signed-off-by: Philippe Mathieu-Daudé (cherry picked from commit b2cc69997924b651c0c6f4037782e25f2e438715) Signed-off-by: Michael Tokarev

hw/audio/hda: fix memory leak on audio setup

2024-11-18T16:30:13+00:00

When SET_STREAM_FORMAT is called, the st->buft timer is overwritten, thus causing a memory leak. This was originally fixed in commit 816139ae6a5 ("hw/audio/hda: fix memory leak on audio setup", 2024-11-14) but that caused the audio to break in SPICE. Fortunately, a simpler fix is possible. The timer only needs to be reset, because the callback is always the same (st->output is set at realize time in hda_audio_init); call to timer_new_ns overkill. Replace it with timer_del and only initialize the timer once; for simplicity, do it even if use_timer is false. An even simpler fix would be to free the old time in hda_audio_setup(). However, it seems better to place the initialization of the timer close to that of st->ouput. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini Reviewed-by: Michael Tokarev Message-ID: <20241114125318.1707590-3-pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé (cherry picked from commit 626b39006d2f9b1378a04cb88a2187bb852cb055) Signed-off-by: Michael Tokarev

hw/misc/mos6522: Fix bad class definition of the MOS6522 device

2024-11-18T16:28:53+00:00

When compiling QEMU with --enable-cfi, the "q800" m68k machine currently crashes very early, when the q800_machine_init() function tries to wire the interrupts of the "via1" device. This happens because TYPE_MOS6522_Q800_VIA1 is supposed to be a proper SysBus device, but its parent (TYPE_MOS6522) has a mistake in its class definition where it is only derived from DeviceClass, and not from SysBusDeviceClass, so we end up in funny memory access issues here. Using the right class hierarchy for the MOS6522 device fixes the problem. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2675 Signed-off-by: Thomas Huth Fixes: 51f233ec92 ("misc: introduce new mos6522 VIA device") Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Mark Cave-Ayland Message-ID: <20241114104653.963812-1-thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé (cherry picked from commit c3d7c18b0d616cf7fb3c1f325503e1462307209d) Signed-off-by: Michael Tokarev

tcg: Allow top bit of SIMD_DATA_BITS to be set in simd_desc()

2024-11-17T03:41:49+00:00

In simd_desc() we create a SIMD descriptor from various pieces including an arbitrary data value from the caller. We try to sanitize these to make sure everything will fit: the 'data' value needs to fit in the SIMD_DATA_BITS (== 22) sized field. However we do that sanitizing with: tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS)); This works for the case where the data is supposed to be considered as a signed integer (which can then be returned via simd_data()). However, some callers want to treat the data value as unsigned. Specifically, for the Arm SVE operations, make_svemte_desc() assembles a data value as a collection of fields, and it needs to use all 22 bits. Currently if MTE is enabled then its MTEDESC SIZEM1 field may have the most significant bit set, and then it will trip this assertion. Loosen the assertion so that we only check that the data value will fit into the field in some way, either as a signed or as an unsigned value. This means we will fail to detect some kinds of bug in the callers, but we won't spuriously assert for intentional use of the data field as unsigned. Cc: qemu-stable@nongnu.org Fixes: db432672dc50e ("tcg: Add generic vector expanders") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2601 Signed-off-by: Peter Maydell Message-ID: <20241115172515.1229393-1-peter.maydell@linaro.org> Reviewed-by: Richard Henderson Signed-off-by: Richard Henderson (cherry picked from commit 8377e3fb854d126ba10e61cb6b60885af8443ad4) Signed-off-by: Michael Tokarev

target/arm: Drop user-only special case in sve_stN_r

2024-11-17T03:28:50+00:00

This path is reachable with plugins enabled, and provoked with run-plugin-catch-syscalls-with-libinline.so. Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell Signed-off-by: Richard Henderson Message-ID: <20241112141232.321354-1-richard.henderson@linaro.org> (cherry picked from commit f27550804688da43c6e0d87b2f9e143adbf76271) Signed-off-by: Michael Tokarev

linux-user: Fix setreuid and setregid to use direct syscalls

2024-11-17T03:28:27+00:00

The commit fd6f7798ac30 ("linux-user: Use direct syscalls for setuid(), etc") added direct syscall wrappers for setuid(), setgid(), etc since the system calls have different semantics than the libc functions. Add and use the corresponding wrappers for setreuid and setregid which were missed in that commit. This fixes the build of the debian package of the uid_wrapper library (https://cwrap.org/uid_wrapper.html) when running linux-user. Cc: qemu-stable@nongnu.org Signed-off-by: Helge Deller Reviewed-by: Richard Henderson Reviewed-by: Ilya Leoshkevich Message-ID: Signed-off-by: Richard Henderson (cherry picked from commit 8491026a08b417b2d4070f7c373dcb43134c5312) Signed-off-by: Michael Tokarev

target/i386: Fix legacy page table walk

2024-11-13T15:19:13+00:00

Commit b56617bbcb4 ("target/i386: Walk NPT in guest real mode") added logic to run the page table walker even in real mode if we are in NPT mode. That function then determined whether real mode or paging is active based on whether the pg_mode variable was 0. Unfortunately pg_mode is 0 in two situations: 1) Paging is disabled (real mode) 2) Paging is in 2-level paging mode (32bit without PAE) That means the walker now assumed that 2-level paging mode was real mode, breaking NetBSD as well as Windows XP. To fix that, this patch adds a new PG flag to pg_mode which indicates whether paging is active at all and uses that to determine whether we are in real mode or not. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2654 Fixes: b56617bbcb4 ("target/i386: Walk NPT in guest real mode") Fixes: 253c0a06e03 (commit b56617bbcb4 in stable-7.2.x series) Signed-off-by: Alexander Graf Reported-by: Mark Cave-Ayland Link: https://lore.kernel.org/r/20241106154329.67218-1-graf@amazon.com Signed-off-by: Paolo Bonzini (cherry picked from commit 8fa11a4df344f58375eb26b3b65004345f21ef37) Signed-off-by: Michael Tokarev

9pfs: fix crash on 'Treaddir' request

2024-11-10T08:10:00+00:00

A bad (broken or malicious) 9p client (guest) could cause QEMU host to crash by sending a 9p 'Treaddir' request with a numeric file ID (FID) that was previously opened for a file instead of an expected directory: #0 0x0000762aff8f4919 in __GI___rewinddir (dirp=0xf) at ../sysdeps/unix/sysv/linux/rewinddir.c:29 #1 0x0000557b7625fb40 in do_readdir_many (pdu=0x557bb67d2eb0, fidp=0x557bb67955b0, entries=0x762afe9fff58, offset=0, maxsize=131072, dostat=) at ../hw/9pfs/codir.c:101 #2 v9fs_co_readdir_many (pdu=pdu@entry=0x557bb67d2eb0, fidp=fidp@entry=0x557bb67955b0, entries=entries@entry=0x762afe9fff58, offset=0, maxsize=131072, dostat=false) at ../hw/9pfs/codir.c:226 #3 0x0000557b7625c1f9 in v9fs_do_readdir (pdu=0x557bb67d2eb0, fidp=0x557bb67955b0, offset=, max_count=) at ../hw/9pfs/9p.c:2488 #4 v9fs_readdir (opaque=0x557bb67d2eb0) at ../hw/9pfs/9p.c:2602 That's because V9fsFidOpenState was declared as union type. So the same memory region is used for either an open POSIX file handle (int), or a POSIX DIR* pointer, etc., so 9p server incorrectly used the previously opened (valid) POSIX file handle (0xf) as DIR* pointer, eventually causing a crash in glibc's rewinddir() function. Root cause was therefore a missing check in 9p server's 'Treaddir' request handler, which must ensure that the client supplied FID was really opened as directory stream before trying to access the aforementioned union and its DIR* member. Cc: qemu-stable@nongnu.org Fixes: d62dbb51f7 ("virtio-9p: Add fidtype so that we can do type ...") Reported-by: Akihiro Suda Tested-by: Akihiro Suda Signed-off-by: Christian Schoenebeck Reviewed-by: Greg Kurz Message-Id: (cherry picked from commit 042b4ebfd2298ae01553844124f27d651cdb1071) Signed-off-by: Michael Tokarev

hw/nvme: fix handling of over-committed queues

2024-11-10T08:10:00+00:00

If a host chooses to use the SQHD "hint" in the CQE to know if there is room in the submission queue for additional commands, it may result in a situation where there are not enough internal resources (struct NvmeRequest) available to process the command. For a lack of a better term, the host may "over-commit" the device (i.e., it may have more inflight commands than the queue size). For example, assume a queue with N entries. The host submits N commands and all are picked up for processing, advancing the head and emptying the queue. Regardless of which of these N commands complete first, the SQHD field of that CQE will indicate to the host that the queue is empty, which allows the host to issue N commands again. However, if the device has not posted CQEs for all the previous commands yet, the device will have less than N resources available to process the commands, so queue processing is suspended. And here lies an 11 year latent bug. In the absense of any additional tail updates on the submission queue, we never schedule the processing bottom-half again unless we observe a head update on an associated full completion queue. This has been sufficient to handle N-to-1 SQ/CQ setups (in the absense of over-commit of course). Incidentially, that "kick all associated SQs" mechanism can now be killed since we now just schedule queue processing when we return a processing resource to a non-empty submission queue, which happens to cover both edge cases. However, we must retain kicking the CQ if it was previously full. So, apparently, no previous driver tested with hw/nvme has ever used SQHD (e.g., neither the Linux NVMe driver or SPDK uses it). But then OSv shows up with the driver that actually does. I salute you. Fixes: f3c507adcd7b ("NVMe: Initial commit for new storage interface") Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2388 Reported-by: Waldemar Kozaczuk Reviewed-by: Keith Busch Signed-off-by: Klaus Jensen (cherry picked from commit 9529aa6bb4d18763f5b4704cb4198bd25cbbee31) Signed-off-by: Michael Tokarev