hw/misc: applesmc: use host osk as default on macs by t0rr3sp3dr0 · Pull Request #1 · utmapp/qemu

t0rr3sp3dr0 · 2021-10-03T16:14:41Z

When running on a Mac, QEMU is able to get the host OSK and use it as
the default value for the AppleSMC device. The OSK query operation
doesn't require administrator privileges and can be executed by any user
on the system. This patch is based on open-source code from Apple, just
like the implementation from VirtualBox.

Apple:
https://opensource.apple.com/source/IOKitUser/IOKitUser-647.6.13/pwr_mgt.subproj/IOPMLibPrivate.c
https://opensource.apple.com/source/PowerManagement/PowerManagement-637.60.1/pmconfigd/PrivateLib.c

VirtualBox:
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/DevSmc.cpp#L516

Signed-off-by: Pedro Tôrres t0rr3sp3dr0@gmail.com

When running on a Mac, QEMU is able to get the host OSK and use it as the default value for the AppleSMC device. The OSK query operation doesn't require administrator privileges and can be executed by any user on the system. This patch is based on open-source code from Apple, just like the implementation from VirtualBox. Apple: https://opensource.apple.com/source/IOKitUser/IOKitUser-647.6.13/pwr_mgt.subproj/IOPMLibPrivate.c https://opensource.apple.com/source/PowerManagement/PowerManagement-637.60.1/pmconfigd/PrivateLib.c VirtualBox: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/DevSmc.cpp#L516 Signed-off-by: Pedro Tôrres <t0rr3sp3dr0@gmail.com>

t0rr3sp3dr0 · 2021-10-03T16:16:20Z

This patch has also been submitted to QEMU: https://patchew.org/QEMU/4E271071-0799-4948-A445-134E7FAAD48D@gmail.com/

It will allow macOS to run on UTM by using the host OSK instead of setting its value manually.

osy · 2021-10-22T22:25:30Z

@t0rr3sp3dr0 Thanks for the pull request. Can you ping me once the conversation with QEMU is resolved? Even if they don't accept the patch, I can still merge it in this branch. But I just want things to be as consistent as possible so if they do accept it, I don't want to diverge on the implementation with QEMU master.

Fix warnings such: disas/nanomips.c:3251:64: warning: format specifies type 'char *' but the argument has type 'int64' (aka 'long long') [-Wformat] return img_format("CACHE 0x%" PRIx64 ", %s(%s)", op_value, s_value, rs); ~~ ^~~~~~~ %lld To avoid crashes such (kernel from commit f375ad6): $ qemu-system-mipsel -cpu I7200 -d in_asm -kernel generic_nano32r6el_page4k ... ---------------- IN: __bzero 0x805c6084: 20c4 6950 ADDU r13, a0, a2 0x805c6088: 9089 ADDIU a0, 1 Process 70261 stopped * thread #6, stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0) frame #0: 0x00000001bfe38864 libsystem_platform.dylib`_platform_strlen + 4 libsystem_platform.dylib`: -> 0x1bfe38864 <+4>: ldr q0, [x1] 0x1bfe38868 <+8>: adr x3, #-0xc8 ; ___lldb_unnamed_symbol314 0x1bfe3886c <+12>: ldr q2, [x3], #0x10 0x1bfe38870 <+16>: and x2, x0, #0xf Target 0: (qemu-system-mipsel) stopped. (lldb) bt * thread #6, stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0) * frame #0: 0x00000001bfe38864 libsystem_platform.dylib`_platform_strlen + 4 frame #1: 0x00000001bfce76a0 libsystem_c.dylib`__vfprintf + 4544 frame #2: 0x00000001bfd158b4 libsystem_c.dylib`_vasprintf + 280 frame #3: 0x0000000101c22fb0 libglib-2.0.0.dylib`g_vasprintf + 28 frame #4: 0x0000000101bfb7d8 libglib-2.0.0.dylib`g_strdup_vprintf + 32 frame #5: 0x000000010000fb70 qemu-system-mipsel`img_format(format=<unavailable>) at nanomips.c:103:14 [opt] frame #6: 0x0000000100018868 qemu-system-mipsel`SB_S9_(instruction=<unavailable>, info=<unavailable>) at nanomips.c:12616:12 [opt] frame #7: 0x000000010000f90c qemu-system-mipsel`print_insn_nanomips at nanomips.c:589:28 [opt] Fixes: 4066c15 ("disas/nanomips: Remove IMMEDIATE functions") Reported-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221101114458.25756-2-philmd@linaro.org>

Since commit e99441a ("ui/curses: Do not use console_select()") qemu_text_console_put_keysym() no longer checks for NULL console argument, which leads to a later crash: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at ../ui/console-vc.c:332 332 } else if (s->echo && (keysym == '\r' || keysym == '\n')) { (gdb) bt #0 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at ../ui/console-vc.c:332 #1 0x00005555559e18e5 in qemu_text_console_put_keysym (s=<optimized out>, keysym=<optimized out>) at ../ui/console.c:303 #2 0x00005555559f2e88 in do_key_event (vs=vs@entry=0x5555579045c0, down=down@entry=1, keycode=keycode@entry=60, sym=sym@entry=65471) at ../ui/vnc.c:2034 #3 0x00005555559f845c in ext_key_event (vs=0x5555579045c0, down=1, sym=65471, keycode=<optimized out>) at ../ui/vnc.c:2070 #4 protocol_client_msg (vs=0x5555579045c0, data=<optimized out>, len=<optimized out>) at ../ui/vnc.c:2514 #5 0x00005555559f515c in vnc_client_read (vs=0x5555579045c0) at ../ui/vnc.c:1607 Fixes: e99441a ("ui/curses: Do not use console_select()") Fixes: https://issues.redhat.com/browse/RHEL-50529 Cc: qemu-stable@nongnu.org Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 0e60fc8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

When SET_STREAM_FORMAT is called, we should clear the existing setup. Factor out common function to close a stream. Direct leak of 144 byte(s) in 3 object(s) allocated from: #0 0x7f91d38f7350 in calloc (/lib64/libasan.so.8+0xf7350) (BuildId: a4ad7eb954b390cf00f07fa10952988a41d9fc7a) #1 0x7f91d2ab7871 in g_malloc0 (/lib64/libglib-2.0.so.0+0x64871) (BuildId: 36b60dbd02e796145a982d0151ce37202ec05649) #2 0x562fa2f447ee in timer_new_full /home/elmarco/src/qemu/include/qemu/timer.h:538 #3 0x562fa2f4486f in timer_new /home/elmarco/src/qemu/include/qemu/timer.h:559 #4 0x562fa2f448a9 in timer_new_ns /home/elmarco/src/qemu/include/qemu/timer.h:577 #5 0x562fa2f47955 in hda_audio_setup ../hw/audio/hda-codec.c:490 #6 0x562fa2f4897e in hda_audio_command ../hw/audio/hda-codec.c:605 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-ID: <20241008125028.1177932-3-marcandre.lureau@redhat.com> (cherry picked from commit 6d6e233) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

qemu-ga on a NetBSD -current VM terminates with a SIGSEGV upon receiving 'guest-set-time' command... Core was generated by `qemu-ga'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20, str=str@entry=0xffffff922a18) at ../qga/commands-posix.c:88 88 *str[len] = '\0'; [Current thread is 1 (process 1112)] (gdb) bt #0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20, str=str@entry=0xffffff922a18) at ../qga/commands-posix.c:88 #1 0x000000000cd37b60 in ga_run_command (argv=argv@entry=0xffffff922a90, action=action@entry=0xcda34b8 "set hardware clock to system time", errp=errp@entry=0xffffff922a70, in_str=0x0) at ../qga/commands-posix.c:164 #2 0x000000000cd380c4 in qmp_guest_set_time (has_time=<optimized out>, time_ns=<optimized out>, errp=errp@entry=0xffffff922ad0) at ../qga/commands-posix.c:304 #3 0x000000000cd253d8 in qmp_marshal_guest_set_time (args=<optimized out>, ret=<optimized out>, errp=0xffffff922b48) at qga/qga-qapi-commands.c:193 #4 0x000000000cd4e71c in qmp_dispatch (cmds=cmds@entry=0xcdf5b18 <ga_commands>, request=request@entry=0xf3c711a4b000, allow_oob=allow_oob@entry=false, cur_mon=cur_mon@entry=0x0) at ../qapi/qmp-dispatch.c:220 #5 0x000000000cd36524 in process_event (opaque=0xf3c711a79000, obj=0xf3c711a4b000, err=0x0) at ../qga/main.c:677 #6 0x000000000cd526f0 in json_message_process_token (lexer=lexer@entry=0xf3c711a79018, input=0xf3c712072480, type=type@entry=JSON_RCURLY, x=28, y=1) at ../qobject/json-streamer.c:99 #7 0x000000000cd93860 in json_lexer_feed_char (lexer=lexer@entry=0xf3c711a79018, ch=125 '}', flush=flush@entry=false) at ../qobject/json-lexer.c:313 #8 0x000000000cd93a00 in json_lexer_feed (lexer=lexer@entry=0xf3c711a79018, buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n", size=<optimized out>) at ../qobject/json-lexer.c:350 #9 0x000000000cd5290c in json_message_parser_feed (parser=parser@entry=0xf3c711a79000, buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n", size=<optimized out>) at ../qobject/json-streamer.c:121 #10 0x000000000cd361fc in channel_event_cb (condition=<optimized out>, data=0xf3c711a79000) at ../qga/main.c:703 #11 0x000000000cd3710c in ga_channel_client_event (channel=<optimized out>, condition=<optimized out>, data=0xf3c711b2d300) at ../qga/channel-posix.c:94 #12 0x0000f3c7120d9bec in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0 #13 0x0000f3c7120dd25c in g_main_context_iterate_unlocked.constprop () from /usr/pkg/lib/libglib-2.0.so.0 #14 0x0000f3c7120ddbf0 in g_main_loop_run () from /usr/pkg/lib/libglib-2.0.so.0 #15 0x000000000cda00d8 in run_agent_once (s=0xf3c711a79000) at ../qga/main.c:1522 #16 run_agent (s=0xf3c711a79000) at ../qga/main.c:1559 #17 main (argc=<optimized out>, argv=<optimized out>) at ../qga/main.c:1671 (gdb) The commandline options used on the host machine... qemu-system-aarch64 \ -machine type=virt,pflash0=rom \ -m 8G \ -cpu host \ -smp 8 \ -accel hvf \ -device virtio-net-pci,netdev=unet \ -device virtio-blk-pci,drive=hd \ -drive file=netbsd.qcow2,if=none,id=hd \ -netdev user,id=unet,hostfwd=tcp::2223-:22 \ -object rng-random,filename=/dev/urandom,id=viornd0 \ -device virtio-rng-pci,rng=viornd0 \ -serial mon:stdio \ -display none \ -blockdev node-name=rom,driver=file,filename=/opt/homebrew/Cellar/qemu/9.0.2/share/qemu/edk2-aarch64-code.fd,read-only=true \ -chardev socket,path=/tmp/qga_netbsd.sock,server=on,wait=off,id=qga0 \ -device virtio-serial \ -device virtconsole,chardev=qga0,name=org.qemu.guest_agent.0 This patch rectifies the operator precedence while assigning the NUL terminator. Fixes: c3f32c1 Signed-off-by: Sunil Nimmagadda <sunil@nimmagadda.net> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Link: https://lore.kernel.org/r/m15xppk9qg.fsf@nimmagadda.net Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> (cherry picked from commit 9cfe110) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

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=<optimized out>) 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=<optimized out>, max_count=<optimized out>) 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: d62dbb5 ("virtio-9p: Add fidtype so that we can do type ...") Reported-by: Akihiro Suda <suda.kyoto@gmail.com> Tested-by: Akihiro Suda <suda.kyoto@gmail.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <E1t8GnN-002RS8-E2@kylie.crudebyte.com> (cherry picked from commit 042b4eb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

While running the new GPU tests it was noted that the proprietary nVidia driver barfed when run under the sanitiser: 2025-02-20 11:13:08,226: [11:13:07.782] Output 'headless' attempts EOTF mode SDR and colorimetry mode default. 2025-02-20 11:13:08,227: [11:13:07.784] Output 'headless' using color profile: stock sRGB color profile and that's the last thing it outputs. The sanitizer reports that when the framework sends the SIGTERM because of the timeout we get a write to a NULL pointer (but interesting not this time in an atexit callback): UndefinedBehaviorSanitizer:DEADLYSIGNAL ==471863==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7a18ceaafe80 bp 0x000000000000 sp 0x7ffe8e3ff6d0 T471863) ==471863==The signal is caused by a WRITE memory access. ==471863==Hint: address points to the zero page. #0 0x7a18ceaafe80 (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x16afe80) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #1 0x7a18ce9e72c0 (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x15e72c0) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #2 0x7a18ce9f11bb (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x15f11bb) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #3 0x7a18ce6dc9d1 (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x12dc9d1) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #4 0x7a18e7d15326 in vrend_renderer_create_fence /usr/src/virglrenderer-1.0.0-1ubuntu2/obj-x86_64-linux-gnu/../src/vrend_renderer.c:10883:26 #5 0x55bfb6621871 in virtio_gpu_virgl_process_cmd The #dri-devel channel confirmed: <digetx> stsquad: nv driver is known to not work with venus, don't use it for testing So lets skip running the test to avoid known failures. As we now use vulkaninfo to probe we also need to handle the case where there is no Vulkan driver configured for the hardware. Reviewed-by: Thomas Huth <thuth@redhat.com> Reported-by: Peter Maydell <peter.maydell@linaro.org> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> [AJB: also skip if vulkaninfo can't find environment] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-6-alex.bennee@linaro.org>

On the incoming migration side, QEMU uses a coroutine to load all the VM states. Inside, it may reference MigrationState on global states like migration capabilities, parameters, error state, shared mutexes and more. However there's nothing yet to make sure MigrationState won't get destroyed (e.g. after migration_shutdown()). Meanwhile there's also no API available to remove the incoming coroutine in migration_shutdown(), avoiding it to access the freed elements. There's a bug report showing this can happen and crash dest QEMU when migration is cancelled on source. When it happens, the dest main thread is trying to cleanup everything: #0 qemu_aio_coroutine_enter #1 aio_dispatch_handler #2 aio_poll #3 monitor_cleanup #4 qemu_cleanup #5 qemu_default_main Then it found the migration incoming coroutine, schedule it (even after migration_shutdown()), causing crash: #0 __pthread_kill_implementation #1 __pthread_kill_internal #2 __GI_raise #3 __GI_abort #4 __assert_fail_base #5 __assert_fail #6 qemu_mutex_lock_impl #7 qemu_lockable_mutex_lock #8 qemu_lockable_lock #9 qemu_lockable_auto_lock #10 migrate_set_error #11 process_incoming_migration_co #12 coroutine_trampoline To fix it, take a refcount after an incoming setup is properly done when qmp_migrate_incoming() succeeded the 1st time. As it's during a QMP handler which needs BQL, it means the main loop is still alive (without going into cleanups, which also needs BQL). Releasing the refcount now only until the incoming migration coroutine finished or failed. Hence the refcount is valid for both (1) setup phase of incoming ports, mostly IO watches (e.g. qio_channel_add_watch_full()), and (2) the incoming coroutine itself (process_incoming_migration_co()). Note that we can't unref in migration_incoming_state_destroy(), because both qmp_xen_load_devices_state() and load_snapshot() will use it without an incoming migration. Those hold BQL so they're not prone to this issue. PS: I suspect nobody uses Xen's command at all, as it didn't register yank, hence AFAIU the command should crash on master when trying to unregister yank in migration_incoming_state_destroy().. but that's another story. Also note that in some incoming failure cases we may not always unref the MigrationState refcount, which is a trade-off to keep things simple. We could make it accurate, but it can be an overkill. Some examples: - Unlike most of the rest protocols, socket_start_incoming_migration() may create net listener after incoming port setup sucessfully. It means we can't unref in migration_channel_process_incoming() as a generic path because socket protocol might keep using MigrationState. - For either socket or file, multiple IO watches might be created, it means logically each IO watch needs to take one refcount for MigrationState so as to be 100% accurate on ownership of refcount taken. In general, we at least need per-protocol handling to make it accurate, which can be an overkill if we know incoming failed after all. Add a short comment to explain that when taking the refcount in qmp_migrate_incoming(). Bugzilla: https://issues.redhat.com/browse/RHEL-69775 Tested-by: Yan Fu <yafu@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20250220132459.512610-1-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>

Address a memory leak bug in the usages of timer_del(). The issue arises from the incorrect use of the ambiguous timer API timer_del(), which does not free the timer object. The LeakSanitizer report this issue during fuzzing. The correct API timer_free() freed the timer object instead. ================================================================= ==2586273==ERROR: LeakSanitizer: detected memory leaks Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x55f2afd89879 in calloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:75:3 #1 0x7f443b93ac50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) #2 0x55f2b053962e in timer_new include/qemu/timer.h:542:12 #3 0x55f2b0514771 in timer_new_us include/qemu/timer.h:582:12 #4 0x55f2b0514288 in lsi_scsi_realize hw/scsi/lsi53c895a.c:2350:24 #5 0x55f2b0452d26 in pci_qdev_realize hw/pci/pci.c:2174:9 Signed-off-by: Zheng Huang <hz1624917200@outlook.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <73cd69f9-ff9b-4cd4-b8aa-265f9d6067b9@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>

ASAN spotted a leaking string in machine_set_loadparm(): Direct leak of 9 byte(s) in 1 object(s) allocated from: #0 0x560ffb5bb379 in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 #1 0x7f1aca926518 in g_malloc ../glib/gmem.c:106 #2 0x7f1aca94113e in g_strdup ../glib/gstrfuncs.c:364 #3 0x560ffc8afbf9 in qobject_input_type_str ../qapi/qobject-input-visitor.c:542:12 #4 0x560ffc8a80ff in visit_type_str ../qapi/qapi-visit-core.c:349:10 #5 0x560ffbe6053a in machine_set_loadparm ../hw/s390x/s390-virtio-ccw.c:802:10 #6 0x560ffc0c5e52 in object_property_set ../qom/object.c:1450:5 #7 0x560ffc0d4175 in object_property_set_qobject ../qom/qom-qobject.c:28:10 #8 0x560ffc0c6004 in object_property_set_str ../qom/object.c:1458:15 #9 0x560ffbe2ae60 in update_machine_ipl_properties ../hw/s390x/ipl.c:569:9 #10 0x560ffbe2aa65 in s390_ipl_update_diag308 ../hw/s390x/ipl.c:594:5 #11 0x560ffbdee132 in handle_diag_308 ../target/s390x/diag.c:147:9 #12 0x560ffbebb956 in helper_diag ../target/s390x/tcg/misc_helper.c:137:9 #13 0x7f1a3c51c730 (/memfd:tcg-jit (deleted)+0x39730) Cc: qemu-stable@nongnu.org Signed-off-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20250509174938.25935-1-farosas@suse.de> Fixes: 1fd396e ("s390x: Register TYPE_S390_CCW_MACHINE properties as class properties") Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit bdf12f2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

The hardware stores the instruction code in the lower bits of the FP exception register #1 on FP assist traps. This fixes the FP exception handler on Linux, as the Linux kernel uses the value to decide on the correct signal which should be pushed into userspace (see decode_fpu() in Linux kernel). Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit 923976d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Improve the linux-user emulation to send the correct si_code depending on overflow (TARGET_FPE_FLTOVF), underflow (TARGET_FPE_FLTUND), ... Note that the hardware stores the relevant flags in FP exception register #1, which is actually the lower 32-bits of the 64-bit fr[0] register in qemu. Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit b4b49cf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Implement FP exception register #1 (lower 32-bits of 64-bit fr[0]). A proper implementation is necessary to allow the Linux kernel in system mode and the qemu linux-user to send proper si_code values on SIGFPE signal. Always set the T-bit on taken exception, and merge over- and underflow in system mode to just set overflow bit to mimic the behaviour I tested on a physical machine. The test program below can be used to verify correct behaviour. Note that behaviour on SIGFPE may vary on different platforms. The program should always detect the correct signal, but it may or may not be able to sucessfully continue afterwards. #define _GNU_SOURCE #include <signal.h> #include <stdio.h> #include <fenv.h> #include <float.h> static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main(int argc, char *argv[]) { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW | FE_UNDERFLOW); double x = DBL_MIN; return printf("%lf\n", argc > 1 ? 1.7976931348623158E308*1.7976931348623158E308 : x / 10); } Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit ebd3949) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Commit e27194e ("virtio-gpu-virgl: correct parent for blob memory region") made the name member of MemoryRegion unset, causing a NULL pointer dereference[1]: > Thread 2 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. > (gdb) bt > #0 0x00007ffff56565e2 in __strcmp_evex () at /lib64/libc.so.6 > #1 0x0000555555841bdb in find_fd (head=0x5555572337d0 <cpr_state>, > name=0x0, id=0) at ../migration/cpr.c:68 > #2 cpr_delete_fd (name=name@entry=0x0, id=id@entry=0) at > ../migration/cpr.c:77 > #3 0x000055555582290a in qemu_ram_free (block=0x7ff7e93aa7f0) at > ../system/physmem.c:2615 > #4 0x000055555581ae02 in memory_region_finalize (obj=<optimized out>) > at ../system/memory.c:1816 > #5 0x0000555555a70ab9 in object_deinit (obj=<optimized out>, > type=<optimized out>) at ../qom/object.c:715 > #6 object_finalize (data=0x7ff7e936eff0) at ../qom/object.c:729 > #7 object_unref (objptr=0x7ff7e936eff0) at ../qom/object.c:1232 > #8 0x0000555555814fae in memory_region_unref (mr=<optimized out>) at > ../system/memory.c:1848 > #9 flatview_destroy (view=0x555559ed6c40) at ../system/memory.c:301 > #10 0x0000555555bfc122 in call_rcu_thread (opaque=<optimized out>) at > ../util/rcu.c:324 > #11 0x0000555555bf17a7 in qemu_thread_start (args=0x555557b99520) at > ../util/qemu-thread-posix.c:393 > #12 0x00007ffff556f464 in start_thread () at /lib64/libc.so.6 > #13 0x00007ffff55f25ac in __clone3 () at /lib64/libc.so.6 The intention of the aforementioned commit is to prevent a MemoryRegion from parenting itself while its references is counted indendependently of the device. To achieve the same goal, add a type of QOM objects that count references and parent MemoryRegions. [1] https://lore.kernel.org/qemu-devel/4eb93d7a-1fa9-4b3c-8ad7-a2eb64f025a0@collabora.com/ Cc: qemu-stable@nongnu.org Fixes: e27194e ("virtio-gpu-virgl: correct parent for blob memory region") Fixes: 8d5a8eb ("virtio-gpu-virgl: correct parent for blob memory region") in 10.0.x Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Joelle van Dyne <j@getutm.app> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20260214-region-v1-1-229f00ae1f38@rsg.ci.i.u-tokyo.ac.jp> (cherry picked from commit b2a2790) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit b99e2f4)

Without psci_conduit, the Linux kernel crashes almost immediately. psci: probing for conduit method from DT. Internal error: Oops - Undefined instruction: 0000000002000000 [#1] PREEMPT SMP Fixes: ae0c4d1 ("hw/arm: Add NPCM8XX SoC") Cc: qemu-stable@nongnu.org Cc: Hao Wu <wuhaotsh@google.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20250315142050.3642741-1-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit e6bc017) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In stm32f250_soc_initfn() we mostly use the standard pattern for child objects of calling object_initialize_child(). However for s->adc_irqs we call object_new() and then later qdev_realize(), and we never unref the object on deinit. This causes a leak, detected by ASAN on the device-introspect-test: Indirect leak of 10 byte(s) in 1 object(s) allocated from: #0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe) #1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10 #4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18 #5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12 #6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10 #7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12 #8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9 #9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5 #10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5 #11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9 #12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5 #13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5 #14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12 #15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26 Switch to using object_initialize_child() like all our other child objects for this SoC object. Cc: qemu-stable@nongnu.org Fixes: b63041c ("STM32F205: Connect the ADC devices") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org (cherry picked from commit 2e27650) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In pca9554_set_pin() we have a string property which we parse in order to set some non-string fields in the device state. So we call visit_type_str(), passing it the address of the local variable state_str. visit_type_str() will allocate a new copy of the string; we never free this string, so the result is a memory leak, detected by ASAN during a "make check" run: Direct leak of 5 byte(s) in 1 object(s) allocated from: #0 0x5d605212ede3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) ( BuildId: 3d5373c89317f58bfcd191a33988c7347714be14) #1 0x7f7edea57b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75) #2 0x7f7edea6d4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75) #3 0x5d6055289a91 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10 #4 0x5d6055289a91 in qobject_input_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qo bject-input-visitor.c:542:12 #5 0x5d605528479c in visit_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qapi-visit -core.c:349:10 #6 0x5d60528bdd87 in pca9554_set_pin /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/gpio/pca9554.c:179:10 #7 0x5d60549bcbbb in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1450:5 #8 0x5d60549d2055 in object_property_set_qobject /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/qom-qobject.c:28:10 #9 0x5d60549bcdf1 in object_property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1458:15 #10 0x5d605439d077 in gb200nvl_bmc_i2c_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:1267:5 #11 0x5d60543a3bbc in aspeed_machine_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:493:9 Make the state_str g_autofree, so that we will always free it, on both error-exit and success codepaths. Cc: qemu-stable@nongnu.org Fixes: de0c7d5 ("misc: Add a pca9554 GPIO device model") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250821154459.2417976-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 3284d1c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In the dino PCI host bridge device, we call pci_register_root_bus() in the device's instance_init. This is a problem for two reasons * the PCI bridge is then available to the rest of the simulation (e.g. via pci_qdev_find_device()), even though it hasn't yet been realized * we do not attempt to unregister in an instance_deinit, which means that if you go through an instance_init -> deinit lifecycle the freed memory for the host-bridge device is left on the pci_host_bridges list ASAN reports the resulting use-after-free: ==1771223==ERROR: AddressSanitizer: heap-use-after-free on address 0x527000018f80 at pc 0x5b4b9d3369b5 bp 0x7ffd01929980 sp 0x7ffd01929978 WRITE of size 8 at 0x527000018f80 thread T0 #0 0x5b4b9d3369b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5 #1 0x5b4b9d321566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5 #2 0x5b4b9d3215e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5 #3 0x5b4b9d321fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11 #4 0x5b4b9d390521 in dino_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/dino.c:473:16 0x527000018f80 is located 1664 bytes inside of 12384-byte region [0x527000018900,0x52700001b960) freed by thread T0 here: #0 0x5b4b9cab185a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140) #1 0x5b4b9e3ee723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9 #2 0x5b4b9e3e69db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9 #3 0x5b4b9ea6173c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5 #4 0x5b4b9ec4e0f3 in qmp_marshal_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qapi/qapi-commands-qdev.c:65:14 previously allocated by thread T0 here: #0 0x5b4b9cab1af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140) #1 0x799d8270eb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x5b4b9e3e75fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15 #3 0x5b4b9e3e7409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12 #4 0x5b4b9ea609a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11 where we allocated one instance of the dino device, put it on the list, freed it, and then trying to allocate a second instance touches the freed memory on the pci_host_bridges list. Fix this by deferring all the setup of memory regions and registering the PCI bridge to the device's realize method. This brings it into line with almost all other PCI host bridges, which call pci_register_root_bus() in realize. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Fixes: 63901b6 ("dino: move PCI bus initialisation to dino_pcihost_init()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250918114259.1802337-2-peter.maydell@linaro.org> (cherry picked from commit e4a1b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In the astro PCI host bridge device, we call pci_register_root_bus() in the device's instance_init. This is a problem for two reasons * the PCI bridge is then available to the rest of the simulation (e.g. via pci_qdev_find_device()), even though it hasn't yet been realized * we do not attempt to unregister in an instance_deinit, which means that if you go through an instance_init -> deinit lifecycle the freed memory for the host-bridge device is left on the pci_host_bridges list ASAN reports the resulting use-after-free: ==1776584==ERROR: AddressSanitizer: heap-use-after-free on address 0x51f00000cb00 at pc 0x5b2d460a89b5 bp 0x7ffef7617f50 sp 0x7ffef7617f48 WRITE of size 8 at 0x51f00000cb00 thread T0 #0 0x5b2d460a89b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5 #1 0x5b2d46093566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5 #2 0x5b2d460935e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5 #3 0x5b2d46093fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11 #4 0x5b2d46fe2335 in elroy_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/astro.c:455:16 0x51f00000cb00 is located 1664 bytes inside of 3456-byte region [0x51f00000c480,0x51f00000d200) freed by thread T0 here: #0 0x5b2d4582385a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8) #1 0x5b2d47160723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9 #2 0x5b2d471589db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9 #3 0x5b2d477d373c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5 previously allocated by thread T0 here: #0 0x5b2d45823af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8) #1 0x79728fa08b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x5b2d471595fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15 #3 0x5b2d47159409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12 #4 0x5b2d477d29a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11 Cc: qemu-stable@nongnu.org Fixes: e029bb0 ("hw/pci-host: Add Astro system bus adapter found on PA-RISC machines") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250918114259.1802337-3-peter.maydell@linaro.org> (cherry picked from commit 76d2b8d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

When we unrealize a CPU object (which happens on vCPU hot-unplug), we should destroy all the AddressSpace objects we created via calls to cpu_address_space_init() when the CPU was realized. Commit 24bec42 added a function to do this for a specific AddressSpace, but did not add any places where the function was called. Since we always want to destroy all the AddressSpaces on unrealize, regardless of the target architecture, we don't need to try to keep track of how many are still undestroyed, or make the target architecture code manually call a destroy function for each AS it created. Instead we can adjust the function to always completely destroy the whole cpu->ases array, and arrange for it to be called during CPU unrealize as part of the common code. Without this fix, AddressSanitizer will report a leak like this from a run where we hot-plugged and then hot-unplugged an x86 KVM vCPU: Direct leak of 416 byte(s) in 1 object(s) allocated from: #0 0x5b638565053d in calloc (/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/qemu-system-x86_64+0x1ee153d) (BuildId: c1cd6022b195142106e1bffeca23498c2b752bca) #1 0x7c28083f77b1 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x637b1) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x5b6386999c7c in cpu_address_space_init /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../system/physmem.c:797:25 #3 0x5b638727f049 in kvm_cpu_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/kvm/kvm-cpu.c:102:5 #4 0x5b6385745f40 in accel_cpu_common_realize /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../accel/accel-common.c:101:13 #5 0x5b638568fe3c in cpu_exec_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/cpu-common.c:232:10 #6 0x5b63874a2cd5 in x86_cpu_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/cpu.c:9321:5 #7 0x5b6387a0469a in device_set_realized /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:494:13 #8 0x5b6387a27d9e in property_set_bool /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:2375:5 #9 0x5b6387a2090b in object_property_set /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1450:5 #10 0x5b6387a35b05 in object_property_set_qobject /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/qom-qobject.c:28:10 #11 0x5b6387a21739 in object_property_set_bool /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1520:15 #12 0x5b63879fe510 in qdev_realize /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:276:12 Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2517 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20250929144228.1994037-4-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 300a87c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Launch QEMU with $ qemu-img create \ --object secret,id=sec0,data=123456 \ -f luks -o key-secret=sec0 demo.luks 1g $ qemu-system-x86_64 \ --object secret,id=sec0,data=123456 \ -blockdev driver=luks,key-secret=sec0,file.filename=demo.luks,file.driver=file,node-name=luks Then in QMP shell attempt x-blockdev-amend job-id=fish node-name=luks options={'state':'active','new-secret':'sec0','driver':'luks'} It will result in an assertion #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007fad18b73f63 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89 #2 0x00007fad18b19f3e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fad18b016d0 in __GI_abort () at abort.c:77 #4 0x00007fad18b01639 in __assert_fail_base (fmt=<optimized out>, assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=<optimized out>) at assert.c:118 #5 0x00007fad18b120af in __assert_fail (assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=<optimized out>) at assert.c:127 #6 0x000055ff74fdbd46 in bdrv_graph_rdlock_main_loop () at ../block/graph-lock.c:260 #7 0x000055ff7548521b in graph_lockable_auto_lock_mainloop (x=<optimized out>) at /usr/src/debug/qemu-9.2.4-1.fc42.x86_64/include/block/graph-lock.h:266 #8 block_crypto_read_func (block=<optimized out>, offset=4096, buf=0x55ffb6d66ef0 "", buflen=256000, opaque=0x55ffb5edcc30, errp=0x55ffb6f00700) at ../block/crypto.c:71 #9 0x000055ff75439f8b in qcrypto_block_luks_load_key (block=block@entry=0x55ffb5edbe90, slot_idx=slot_idx@entry=0, password=password@entry=0x55ffb67dc260 "123456", masterkey=masterkey@entry=0x55ffb5fb0c40 "", readfunc=readfunc@entry=0x55ff754851e0 <block_crypto_read_func>, opaque=opaque@entry=0x55ffb5edcc30, errp=0x55ffb6f00700) at ../crypto/block-luks.c:927 #10 0x000055ff7543b90f in qcrypto_block_luks_find_key (block=<optimized out>, password=<optimized out>, masterkey=<optimized out>, readfunc=<optimized out>, opaque=<optimized out>, errp=<optimized out>) at ../crypto/block-luks.c:1045 #11 qcrypto_block_luks_amend_add_keyslot (block=0x55ffb5edbe90, readfunc=0x55ff754851e0 <block_crypto_read_func>, writefunc=0x55ff75485100 <block_crypto_write_func>, opaque=0x55ffb5edcc3, opts_luks=0x7fad1715aef8, force=<optimized out>, errp=0x55ffb6f00700) at ../crypto/block-luks.c:1673 #12 qcrypto_block_luks_amend_options (block=0x55ffb5edbe90, readfunc=0x55ff754851e0 <block_crypto_read_func>, writefunc=0x55ff75485100 <block_crypto_write_func>, opaque=0x55ffb5edcc30, options=0x7fad1715aef0, force=<optimized out>, errp=0x55ffb6f00700) at ../crypto/block-luks.c:1865 #13 0x000055ff75485b95 in block_crypto_amend_options_generic_luks (bs=<optimized out>, amend_options=<optimized out>, force=<optimized out>, errp=<optimized out>) at ../block/crypto.c:949 #14 0x000055ff75485c28 in block_crypto_co_amend_luks (bs=<optimized out>, opts=<optimized out>, force=<optimized out>, errp=<optimized out>) at ../block/crypto.c:1008 #15 0x000055ff754778e5 in blockdev_amend_run (job=0x55ffb6f00640, errp=0x55ffb6f00700) at ../block/amend.c:52 #16 0x000055ff75468b90 in job_co_entry (opaque=0x55ffb6f00640) at ../job.c:1106 #17 0x000055ff755a0fc2 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ../util/coroutine-ucontext.c:175 This changes the read/write callbacks to not assert that they are run in mainloop context if already in a coroutine. This is also reproduced by qemu-iotests cases 295 and 296. Fixes: 1f051dc Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20250919112213.1530079-1-berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit c86488a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Commit e27194e ("virtio-gpu-virgl: correct parent for blob memory region") made the name member of MemoryRegion unset, causing a NULL pointer dereference[1]: > Thread 2 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. > (gdb) bt > #0 0x00007ffff56565e2 in __strcmp_evex () at /lib64/libc.so.6 > #1 0x0000555555841bdb in find_fd (head=0x5555572337d0 <cpr_state>, > name=0x0, id=0) at ../migration/cpr.c:68 > #2 cpr_delete_fd (name=name@entry=0x0, id=id@entry=0) at > ../migration/cpr.c:77 > #3 0x000055555582290a in qemu_ram_free (block=0x7ff7e93aa7f0) at > ../system/physmem.c:2615 > #4 0x000055555581ae02 in memory_region_finalize (obj=<optimized out>) > at ../system/memory.c:1816 > #5 0x0000555555a70ab9 in object_deinit (obj=<optimized out>, > type=<optimized out>) at ../qom/object.c:715 > #6 object_finalize (data=0x7ff7e936eff0) at ../qom/object.c:729 > #7 object_unref (objptr=0x7ff7e936eff0) at ../qom/object.c:1232 > #8 0x0000555555814fae in memory_region_unref (mr=<optimized out>) at > ../system/memory.c:1848 > #9 flatview_destroy (view=0x555559ed6c40) at ../system/memory.c:301 > #10 0x0000555555bfc122 in call_rcu_thread (opaque=<optimized out>) at > ../util/rcu.c:324 > #11 0x0000555555bf17a7 in qemu_thread_start (args=0x555557b99520) at > ../util/qemu-thread-posix.c:393 > #12 0x00007ffff556f464 in start_thread () at /lib64/libc.so.6 > #13 0x00007ffff55f25ac in __clone3 () at /lib64/libc.so.6 The intention of the aforementioned commit is to prevent a MemoryRegion from parenting itself while its references is counted indendependently of the device. To achieve the same goal, add a type of QOM objects that count references and parent MemoryRegions. [1] https://lore.kernel.org/qemu-devel/4eb93d7a-1fa9-4b3c-8ad7-a2eb64f025a0@collabora.com/ Cc: qemu-stable@nongnu.org Fixes: e27194e ("virtio-gpu-virgl: correct parent for blob memory region") Fixes: 8d5a8eb ("virtio-gpu-virgl: correct parent for blob memory region") in 10.0.x Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Joelle van Dyne <j@getutm.app> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20260214-region-v1-1-229f00ae1f38@rsg.ci.i.u-tokyo.ac.jp> (cherry picked from commit b2a2790) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Fedora QA reported the following kernel panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1082ec067 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-0.rc4.260108gf0b9d8eb98df.34.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 Code: 48 83 c4 20 5b e9 69 f0 fc fe 8b 05 a0 c1 b2 01 85 c0 74 23 b8 68 58 4d 56 b9 27 00 00 00 31 d2 bb 04 00 00 00 66 ba 58 56 ed <89> 1f 89 0e 41 89 10 5b e9 3c f0 fc fe 6a 00 49 89 f9 45 31 c0 31 RSP: 0018:ff5eeb3240003e40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 000000000000ffca RCX: 000000000000ffac RDX: 0000000000000000 RSI: 0000000040003e58 RDI: 0000000040003e54 RBP: ff1e05f3c1204800 R08: ff5eeb3240003e5c R09: 000000009d899c41 R10: 000000000000003d R11: ff5eeb3240003ff8 R12: 0000000000000000 R13: 00000000000000ff R14: ff1e05f3c02f9e00 R15: 000000000000000c FS: 0000000000000000(0000) GS:ff1e05f489e40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000040003e54 CR3: 000000010841d002 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <IRQ> vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ... It was triggered by dereferencing a bad pointer (RDI) immediately after a VMware hypercall for VMWARE_CMD_ABSPOINTER_DATA in the vmmouse driver: ffffffff82135070 <vmware_hypercall4.constprop.0>: ... ffffffff821350ac: b8 68 58 4d 56 mov $0x564d5868,%eax ffffffff821350b1: b9 27 00 00 00 mov $0x27,%ecx ffffffff821350b6: 31 d2 xor %edx,%edx ffffffff821350b8: bb 04 00 00 00 mov $0x4,%ebx ffffffff821350bd: 66 ba 58 56 mov $0x5658,%dx ffffffff821350c1: ed in (%dx),%eax <-- hypercall ffffffff821350c2: 89 1f mov %ebx,(%rdi) <-- crash Reading the kernel disassembly shows that RDI should contain the value of a valid kernel stack address here (0xff5eeb3240003e54). Instead it contains 0x40003e54, suggesting the hypervisor cleared the upper 32 bits. And indeed, Alexey discovered that QEMU's vmmouse_get_data() and vmmouse_set_data() are only saving/restoring the lower 32 bits, while clearing the upper 32. Fix that by changing the type of the saved data array from uint32_t to uint64_t. Fixes: 548df2a ("VMMouse Emulation, by Anthony Liguori.") Reported-by: Justin Forbes <jforbes@fedoraproject.org> Debugged-by: Alexey Makhalov <alexey.makhalov@broadcom.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/c508fc1d4a4ccd8c9fb1e51b71df089e31115a53.1770309998.git.jpoimboe@kernel.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3293 Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 48c8916) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Details: https://gitlab.com/qemu-project/qemu/-/issues/3144 The function schedule_next_request is called with tg->lock held and it may call throttle_group_co_restart_queue, which takes tgm->throttled_reqs_lock, qemu_co_mutex_lock may leave current coroutine if other iothread has taken the lock. If the next coroutine will call throttle_group_co_io_limits_intercept - it will try to take the mutex tg->lock which will never be released. Here is the backtrace of the iothread: Thread 30 (Thread 0x7f8aad1fd6c0 (LWP 24240) "IO iothread2"): #0 futex_wait (futex_word=0x5611adb7d828, expected=2, private=0) at ../sysdeps/nptl/futex-internal.h:146 #1 __GI___lll_lock_wait (futex=futex@entry=0x5611adb7d828, private=0) at lowlevellock.c:49 #2 0x00007f8ab5a97501 in lll_mutex_lock_optimized (mutex=0x5611adb7d828) at pthread_mutex_lock.c:48 #3 ___pthread_mutex_lock (mutex=0x5611adb7d828) at pthread_mutex_lock.c:93 #4 0x00005611823f5482 in qemu_mutex_lock_impl (mutex=0x5611adb7d828, file=0x56118289daca "../block/throttle-groups.c", line=372) at ../util/qemu-thread-posix.c:94 #5 0x00005611822b0b39 in throttle_group_co_io_limits_intercept (tgm=0x5611af1bb4d8, bytes=4096, direction=THROTTLE_READ) at ../block/throttle-groups.c:372 #6 0x00005611822473b1 in blk_co_do_preadv_part (blk=0x5611af1bb490, offset=15972311040, bytes=4096, qiov=0x7f8aa4000f98, qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at ../block/block-backend.c:1354 #7 0x0000561182247fa0 in blk_aio_read_entry (opaque=0x7f8aa4005910) at ../block/block-backend.c:1619 #8 0x000056118241952e in coroutine_trampoline (i0=-1543497424, i1=32650) at ../util/coroutine-ucontext.c:175 #9 0x00007f8ab5a56f70 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:66 from target:/lib64/libc.so.6 #10 0x00007f8aad1ef190 in ?? () #11 0x0000000000000000 in ?? () The lock is taken in line 386: (gdb) p tg.lock $1 = {lock = {__data = {__lock = 2, __count = 0, __owner = 24240, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\000\000\000\000\260^\000\000\001", '\000' <repeats 26 times>, __align = 2}, file = 0x56118289daca "../block/throttle-groups.c", line = 386, initialized = true} The solution is to use tg->lock to protect both ThreadGroup fields and ThrottleGroupMember.throttled_reqs. It doesn't seem to be possible to use separate locks because we need to first manipulate ThrottleGroup fields, then schedule next coroutine using throttled_reqs and after than update token field from ThrottleGroup depending on the throttled_reqs state. Signed-off-by: Dmitry Guryanov <dmitry.guryanov@gmail.com> Message-ID: <20251208085528.890098-1-dmitry.guryanov@gmail.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit d481617) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Recent fixes to TLS tasks memory handling have left the TLS bye task uncovered. Fix by freeing the task in the same way the handshake task is freed. Direct leak of 704 byte(s) in 4 object(s) allocated from: #1 0x7f5909b1d6a0 in g_malloc0 ../glib/gmem.c:163 #2 0x557650496d61 in qio_task_new ../io/task.c:58:12 #3 0x557650475d7f in qio_channel_tls_bye ../io/channel-tls.c:352:12 #4 0x55764f7a1bb4 in migration_tls_channel_end ../migration/tls.c:159:5 #5 0x55764f709750 in migration_ioc_shutdown_gracefully ../migration/multifd.c:462:9 #6 0x55764f6fcf53 in multifd_send_terminate_threads ../migration/multifd.c:493:13 #7 0x55764f6fcafb in multifd_send_shutdown ../migration/multifd.c:580:5 #8 0x55764f6e1b14 in migration_cleanup ../migration/migration.c:1323:9 #9 0x55764f6f5bac in migration_cleanup_bh ../migration/migration.c:1350:5 Fixes: d39d0f3 ("io: fix cleanup for TLS I/O source data on cancellation") Fixes: 1b63062 ("io: fix cleanup for TLS I/O source data on cancellation") in 10.0.x series Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Link: https://lore.kernel.org/qemu-devel/20260311213418.16951-3-farosas@suse.de Signed-off-by: Fabiano Rosas <farosas@suse.de> (cherry picked from commit c20f143) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In of_dpa_cmd_add_l2_flood(), we use rocker_tlv_parse_nested() to fill in a tlvs[] array. If the guest command is valid then the entries should be pointers to TLV data items with group IDs. However, if the guest gives us bogus data then rocker_tlv_parse_nested() indicates this by leaving the tlvs[] entries NULL. In the other places that use this function, we check for this before using the value, but here we forgot, and the result is that QEMU can crash: #0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:331 #1 0x00005555574f7137 in __asan_memcpy () #2 0x0000555558106792 in ldl_he_p (ptr=0x8) at /home/pm215/qemu/include/qemu/bswap.h:278 #3 0x0000555558106755 in ldl_le_p (ptr=0x8) at /home/pm215/qemu/include/qemu/bswap.h:311 #4 0x00005555580f85ed in rocker_tlv_get_le32 (tlv=0x0) at ../../hw/net/rocker/rocker_tlv.h:114 #5 0x000055555810a8ad in of_dpa_cmd_add_l2_flood (of_dpa=0x506000082e38, group=0x503000b4e440, group_tlvs=0x7fff68702c20) at ../../hw/net/rocker/rocker_of_dpa.c:2032 #6 0x0000555558108a74 in of_dpa_cmd_group_do (of_dpa=0x506000082e38, group_id=1073741824, group=0x503000b4e440, group_tlvs=0x7fff68702c20) at ../../hw/net/rocker/rocker_of_dpa.c:2115 #7 0x0000555558108730 in of_dpa_cmd_group_add (of_dpa=0x506000082e38, group_id=1073741824, group_tlvs=0x7fff68702c20) at ../../hw/net/rocker/rocker_of_dpa.c:2135 #8 0x00005555580f66ec in of_dpa_group_cmd (of_dpa=0x506000082e38, info=0x514000072e40, buf=0x5070002356c0 "\001", cmd=7, group_tlvs=0x7fff68702c20) at ../../hw/net/rocker/rocker_of_dpa.c:2194 Check for NULL values and return an error. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/1851 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 8526b7d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

It's not possible to access the image file while there is an incoming migration in progress, the QEMU process doesn't hold any locks to the storage at this point so nodes are inactive. Attempting to flush leads to an assert at bdrv_co_write_req_prepare(): assert(!(bs->open_flags & BDRV_O_INACTIVE)) The issue is reproducible by running iotest 181 on a host under cpu load. The migration must coincide with the header already containing the QED_F_NEED_CHECK flag. The sequence of events is as follows, with the respective call stacks referenced below: During block device init, bdrv_qed_attach_aio_context() starts the 'need_check' timer. The timer will not fire during incoming migration as it uses QEMU_CLOCK_VIRTUAL (to avoid this very issue, as the code comment indicates). (0) However, there's still bdrv_qed_drain_begin() which uses the fact that the timer is live to decide whether to start the qed_need_check_timer_entry() directly. (1) The qed_need_check_timer_entry() eventually calls into qed_write_header() -> bdrv_co_pwrite() leading to the assert. (2) Skip creating the 'need_check' timer whenever the image is inactive. The stacks: (0) == issues timer_mod == #6 in qed_start_need_check_timer at ../block/qed.c:340 #7 in bdrv_qed_attach_aio_context at ../block/qed.c:373 #8 in bdrv_qed_do_open at ../block/qed.c:556 #9 in bdrv_qed_open_entry at ../block/qed.c:582 #10 in coroutine_trampoline at ../util/coroutine-ucontext.c:175 #0 in qemu_coroutine_switch<+120> at ../util/coroutine-ucontext.c:321 #1 in qemu_aio_coroutine_enter<+356> at ../util/qemu-coroutine.c:293 #2 in aio_co_enter<+179> at ../util/async.c:710 #3 in aio_co_wake<+53> at ../util/async.c:695 #4 in thread_pool_co_cb<+47> at ../util/thread-pool.c:283 #5 in thread_pool_completion_bh<+241> at ../util/thread-pool.c:202 #6 in aio_bh_call<+109> at ../util/async.c:173 #7 in aio_bh_poll<+299> at ../util/async.c:220 #8 in aio_poll<+690> at ../util/aio-posix.c:745 #9 in bdrv_qed_open<+392> at ../block/qed.c:607 #10 in bdrv_open_driver<+327> at ../block.c:1678 #11 in bdrv_open_common<+1619> at ../block.c:2008 #12 in bdrv_open_inherit<+2556> at ../block.c:4191 #13 in bdrv_open<+118> at ../block.c:4286 #14 in blk_new_open<+199> at ../block/block-backend.c:458 #15 in blockdev_init<+2011> at ../blockdev.c:612 #16 in drive_new<+3008> at ../blockdev.c:1008 #17 in drive_init_func<+51> at ../system/vl.c:662 #18 in qemu_opts_foreach<+227> at ../util/qemu-option.c:1148 #19 in configure_blockdev<+350> at ../system/vl.c:721 #20 in qemu_create_early_backends<+343> at ../system/vl.c:2076 #21 in qemu_init<+12483> at ../system/vl.c:3778 #22 in main<+46> at ../system/main.c:71 (1) == sees timer_pending == #6 in bdrv_qed_drain_begin at ../block/qed.c:391 #7 in bdrv_do_drained_begin at ../block/io.c:366 #8 in bdrv_do_drained_begin_quiesce at ../block/io.c:386 #9 in bdrv_child_cb_drained_begin at ../block.c:1207 #10 in bdrv_parent_drained_begin_single at ../block/io.c:133 #11 in bdrv_parent_drained_begin at ../block/io.c:64 #12 in bdrv_do_drained_begin at ../block/io.c:364 #13 in bdrv_drained_begin at ../block/io.c:393 #14 in blk_drain at ../block/block-backend.c:2101 #15 in blk_unref at ../block/block-backend.c:544 #16 in bdrv_open_inherit at ../block.c:4197 #17 in bdrv_open at ../block.c:4286 #18 in blk_new_open at ../block/block-backend.c:458 #19 in blockdev_init at ../blockdev.c:612 #20 in drive_new at ../blockdev.c:1008 #21 in drive_init_func at ../system/vl.c:662 #22 in qemu_opts_foreach at ../util/qemu-option.c:1148 #23 in configure_blockdev at ../system/vl.c:721 #24 in qemu_create_early_backends at ../system/vl.c:2076 #25 in qemu_init at ../system/vl.c:3778 #26 in main at ../system/main.c:71 (2) == crashes == #5 in __assert_fail (assertion="!(bs->open_flags & BDRV_O_INACTIVE)", file="../block/io.c", line=1977 #6 in bdrv_co_write_req_prepare at ../block/io.c:1977 #7 in bdrv_aligned_pwritev at ../block/io.c:2099 #8 in bdrv_co_pwritev_part at ../block/io.c:2316 #9 in bdrv_co_pwritev at ../block/io.c:2233 #10 in bdrv_co_pwrite at ../include/block/block_int-io.h:77 #11 in qed_write_header at ../block/qed.c:128 #12 in qed_need_check_timer at ../block/qed.c:305 #13 in qed_need_check_timer_entry at ../block/qed.c:319 Note that this issue is not exactly the same as what's been reported in Gitlab, but given how easily this reproduces, I imagine it has to be happening in that setup as well. Link: https://gitlab.com/qemu-project/qemu/-/work_items/3515 Signed-off-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20260603193813.2327596-1-farosas@suse.de> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 7e573b6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

virtio_net_handle_rss() enforces that indirections_len is a non-zero power of two no larger than VIRTIO_NET_RSS_MAX_TABLE_LEN, but virtio_net_rss_post_load() applies none of these checks to values restored from the migration stream. A corrupted save file or crafted migration stream can set indirections_len to 0. Even if it also clears redirect, virtio_load() calls set_features_nocheck() after the device vmstate (including the RSS subsection and its post_load) has already been loaded, re-deriving redirect from the negotiated guest features. When VIRTIO_NET_F_RSS was negotiated, redirect is set back to true regardless of the migration stream value. The receive path then computes hash & (indirections_len - 1) /* wraps to 0xFFFFFFFF via int promotion */ and uses the result to index into indirections_table, which was not allocated by the VMState loader when the element count is zero (see vmstate_handle_alloc()), resulting in a NULL pointer dereference that crashes QEMU: #0 virtio_net_process_rss ../hw/net/virtio-net.c:1901 #1 virtio_net_receive_rcu ../hw/net/virtio-net.c:1921 #2 virtio_net_do_receive ../hw/net/virtio-net.c:2061 #3 nc_sendv_compat ../net/net.c:823 #4 qemu_deliver_packet_iov ../net/net.c:870 The RSS subsection is only loaded when rss_data.enabled is true (via virtio_net_rss_needed()), and the command path always produces indirections_len in {1, 2, 4, …, 128}, so an unconditional check cannot reject a legitimate migration stream. Factor the validation into virtio_net_rss_indirections_len_valid() and call it from both virtio_net_handle_rss() and virtio_net_rss_post_load(). Fixes: e41b711 ("virtio-net: add migration support for RSS and hash report") Cc: qemu-stable@nongnu.org Signed-off-by: Junjie Cao <junjie.cao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260324060100.1997-1-junjie.cao@intel.com> (cherry picked from commit 32a9085) (Mjt: backport to 10.0.x series, introducing small parts of commit v10.0.0-2242-g7b6e7e4990 "virtio-net: Retrieve peer hashing capability" which added virtio_net_rss_post_load() method to vmstate_virtio_net_rss) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

asdfugil pushed a commit to asdfugil/qemu that referenced this pull request Apr 29, 2022

BUILD.md: update as we now fixed issue utmapp#1

6ab36e2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

hw/misc: applesmc: use host osk as default on macs - #1

hw/misc: applesmc: use host osk as default on macs#1
t0rr3sp3dr0 wants to merge 1 commit into
utmapp:utm-edition-v8.0.0from
t0rr3sp3dr0:utm-edition

t0rr3sp3dr0 commented Oct 3, 2021

Uh oh!

t0rr3sp3dr0 commented Oct 3, 2021 •

edited

Loading

Uh oh!

osy commented Oct 22, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

t0rr3sp3dr0 commented Oct 3, 2021

Uh oh!

t0rr3sp3dr0 commented Oct 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

osy commented Oct 22, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

t0rr3sp3dr0 commented Oct 3, 2021 •

edited

Loading