Compiling patchew-qemu on M1 MacBook using Homebrew #1
Comments
patchew-importer
pushed a commit
that referenced
this issue
Dec 12, 2020
When running device-introspect-test, a memory leak occurred in the s390_cpu_initfn
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 3552 byte(s) in 74 object(s) allocated from:
#0 0xfffeb3d4e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xfffeb36e6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaad51a8f9c4 in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaad51a8f9c4 in timer_new qemu/include/qemu/timer.h:544
#4 0xaaad51a8f9c4 in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaad51a8f9c4 in s390_cpu_initfn qemu/target/s390x/cpu.c:304
#6 0xaaad51e00f58 in object_init_with_type qemu/qom/object.c:371
#7 0xaaad51e0406c in object_initialize_with_type qemu/qom/object.c:515
#8 0xaaad51e042e0 in object_new_with_type qemu/qom/object.c:729
#9 0xaaad51e3ff40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#10 0xaaad51910518 in qdev_device_help qemu/softmmu/qdev-monitor.c:283
#11 0xaaad51911918 in qmp_device_add qemu/softmmu/qdev-monitor.c:801
#12 0xaaad51911e48 in hmp_device_add qemu/softmmu/qdev-monitor.c:916
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Cornelia Huck <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Dec 12, 2020
Providing the 'if' property, but not 'canbus' segfaults like this: #0 0x0000555555b0f14d in can_bus_insert_client (bus=0x0, client=0x555556aa9af0) at ../net/can/can_core.c:88 #1 0x00005555559c3803 in can_host_connect (ch=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:62 #2 0x00005555559c386a in can_host_complete (uc=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:72 #3 0x0000555555d52de9 in user_creatable_complete (uc=0x555556aa9ac0, errp=0x7fffffffd5c8) at ../qom/object_interfaces.c:23 Add the missing NULL check. Signed-off-by: Kevin Wolf <[email protected]> Message-Id: <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Dec 14, 2020
When running qom-test, a memory leak occurred in the ppce500_init function,
this patch free irqs array to fix it.
ASAN shows memory leak stack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0xfffc5ceee1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xfffc5c806800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaacf9999244 in ppce500_init qemu/hw/ppc/e500.c:859
#3 0xaaacf97434e8 in machine_run_board_init qemu/hw/core/machine.c:1134
#4 0xaaacf9c9475c in qemu_init qemu/softmmu/vl.c:4369
#5 0xaaacf94785a0 in main qemu/softmmu/main.c:49
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: David Gibson <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Dec 15, 2020
In rom_check_and_register_reset() we report to the user if there is a "ROM region overlap". This has a couple of problems: * the reported information is not very easy to intepret * the function just prints the overlap to stderr (and relies on its single callsite in vl.c to do an error_report() and exit) * only the first overlap encountered is diagnosed Make this function use error_report() and error_printf() and report a more user-friendly report with all the overlaps diagnosed. Sample old output: rom: requested regions overlap (rom dtb. free=0x0000000000008000, addr=0x0000000000000000) qemu-system-aarch64: rom check and register reset failed Sample new output: qemu-system-aarch64: Some ROM regions are overlapping These ROM regions might have been loaded by direct user request or by default. They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. The following two regions overlap (in the cpu-memory-0 address space): phdr #0: /home/petmay01/linaro/qemu-misc-tests/ldmia-fault.axf (addresses 0x0000000000000000 - 0x0000000000008000) dtb (addresses 0x0000000000000000 - 0x0000000000100000) The following two regions overlap (in the cpu-memory-0 address space): phdr #1: /home/petmay01/linaro/qemu-misc-tests/bad-psci-call.axf (addresses 0x0000000040000000 - 0x0000000040000010) phdr #0: /home/petmay01/linaro/qemu-misc-tests/bp-test.elf (addresses 0x0000000040000000 - 0x0000000040000020) Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Message-id: [email protected]
patchew-importer
pushed a commit
that referenced
this issue
Jan 2, 2021
In host_memory_backend_get_host_nodes, we build host_nodes
list and output it to v (a StringOutputVisitor) but forget
to free the list. This fixes the memory leak.
The memory leak stack:
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0xfffda30b3393 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xd3393)
#1 0xfffda1d28b9b in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x58b9b)
#2 0xaaab05ca6e43 in host_memory_backend_get_host_nodes backends/hostmem.c:94
#3 0xaaab061ddf83 in object_property_get_uint16List qom/object.c:1478
#4 0xaaab05866513 in query_memdev hw/core/machine-qmp-cmds.c:312
#5 0xaaab061d980b in do_object_child_foreach qom/object.c:1001
#6 0xaaab0586779b in qmp_query_memdev hw/core/machine-qmp-cmds.c:328
#7 0xaaab0615ed3f in qmp_marshal_query_memdev qapi/qapi-commands-machine.c:327
#8 0xaaab0632d647 in do_qmp_dispatch qapi/qmp-dispatch.c:147
#9 0xaaab0632d647 in qmp_dispatch qapi/qmp-dispatch.c:190
#10 0xaaab0610f74b in monitor_qmp_dispatch monitor/qmp.c:120
#11 0xaaab0611074b in monitor_qmp_bh_dispatcher monitor/qmp.c:209
#12 0xaaab063caefb in aio_bh_poll util/async.c:117
#13 0xaaab063d30fb in aio_dispatch util/aio-posix.c:459
#14 0xaaab063cac8f in aio_ctx_dispatch util/async.c:268
#15 0xfffda1d22a6b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a6b)
#16 0xaaab063d0e97 in glib_pollfds_poll util/main-loop.c:218
#17 0xaaab063d0e97 in os_host_main_loop_wait util/main-loop.c:241
#18 0xaaab063d0e97 in main_loop_wait util/main-loop.c:517
#19 0xaaab05c8bfa7 in main_loop /root/rpmbuild/BUILD/qemu-4.1.0/vl.c:1791
#20 0xaaab05713bc3 in main /root/rpmbuild/BUILD/qemu-4.1.0/vl.c:4473
#21 0xfffda0a83ebf in __libc_start_main (/usr/lib64/libc.so.6+0x23ebf)
#22 0xaaab0571ed5f (aarch64-softmmu/qemu-system-aarch64+0x88ed5f)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s).
Fixes: 4cf1b76 (hostmem: add properties for NUMA memory policy)
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Keqian Zhu <[email protected]>
Tested-by: Chen Qun <[email protected]>
Reviewed-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Eduardo Habkost <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 6, 2021
The kernel comes from debian archive so it's trusted. Invoking the test can be done as follows: $ avocado --show=app,console run -t machine:fuloong2e tests/acceptance/ (1/1) tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips64el_fuloong2e: console: [ 0.000000] Initializing cgroup subsys cpuset console: [ 0.000000] Initializing cgroup subsys cpu console: [ 0.000000] Initializing cgroup subsys cpuacct console: [ 0.000000] Linux version 3.16.0-6-loongson-2e ([email protected]) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.56-1+deb8u1 (2018-05-08) console: [ 0.000000] memsize=256, highmemsize=0 console: [ 0.000000] CpuClock = 533080000 console: [ 0.000000] bootconsole [early0] enabled console: [ 0.000000] CPU0 revision is: 00006302 (ICT Loongson-2) console: [ 0.000000] FPU revision is: 00000501 console: [ 0.000000] Checking for the multiply/shift bug... no. console: [ 0.000000] Checking for the daddiu bug... no. console: [ 0.000000] Determined physical RAM map: console: [ 0.000000] memory: 0000000010000000 @ 0000000000000000 (usable) console: [ 0.000000] memory: 0000000004000000 @ 0000000010000000 (reserved) console: [ 0.000000] memory: 0000000003ffffff @ 000000001c000001 (reserved) console: [ 0.000000] Initrd not found or empty - disabling initrd console: [ 0.000000] Zone ranges: console: [ 0.000000] DMA [mem 0x00000000-0x00ffffff] console: [ 0.000000] Normal [mem 0x01000000-0x0fffffff] console: [ 0.000000] Movable zone start for each node console: [ 0.000000] Early memory node ranges console: [ 0.000000] node 0: [mem 0x00000000-0x0fffffff] console: [ 0.000000] Reserving 0MB of memory at 0MB for crashkernel console: [ 0.000000] Primary instruction cache 64kB, VIPT, direct mapped, linesize 32 bytes. console: [ 0.000000] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes console: [ 0.000000] Unified secondary cache 512kB 4-way, linesize 32 bytes. console: [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16327 console: [ 0.000000] Kernel command line: printk.time=0 console=ttyS0 PASS (2.27 s) Signed-off-by: Jiaxun Yang <[email protected]> Reviewed-by: Wainer dos Santos Moschetta <[email protected]> Reviewed-by: Willian Rampazzo <[email protected]> Reviewed-by: Huacai Chen <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Tested-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> [PMD: Added command line example] Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
…eaks
When running device-introspect-test, a memory leak occurred in the
digic_timer_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 288 byte(s) in 3 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
…d memleaks
When running device-introspect-test, a memory leak occurred in the a10_pit_init
function, so use ptimer_free() in the finalize function to avoid it.
ASAN shows memory leak stack:
Indirect leak of 288 byte(s) in 6 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49
#11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
…emleaks
When running device-introspect-test, a memory leak occurred in the
exynos4210_rtc_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
…emleaks
When running device-introspect-test, a memory leak occurred in the
exynos4210_pwm_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 240 byte(s) in 5 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
When running device-introspect-test, a memory leak occurred in the
mss_timer_init function, so use ptimer_free() in the finalize function to avoid
it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 2 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
When running device-introspect-test, a memory leak occurred in the
mv88w8618_pit_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862
#7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283
#12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 8, 2021
…emleaks
When running device-introspect-test, a memory leak occurred in the
exynos4210_mct_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 11, 2021
When the length of mname is less than 5, memcpy("xenfv", mname, 5) will cause
heap buffer overflow. Therefore, use strncmp to avoid this problem.
The asan showed stack:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000f2f4 at
pc 0x7f65d8cc2225 bp 0x7ffe93cc5a60 sp 0x7ffe93cc5208 READ of size 5 at
0x60200000f2f4 thread T0
#0 0x7f65d8cc2224 in memcmp (/lib64/libasan.so.5+0xdf224)
#1 0x5632c20be95b in qtest_cb_for_every_machine tests/qtest/libqtest.c:1282
#2 0x5632c20b7995 in main tests/qtest/test-hmp.c:160
#3 0x7f65d88fed42 in __libc_start_main (/lib64/libc.so.6+0x26d42)
#4 0x5632c20b72cd in _start (build/tests/qtest/test-hmp+0x542cd)
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 18, 2021
When running device-introspect-test, a memory leak occurred in the pl031_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf5621cfc in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544
#4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194
#6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515
#7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729
#8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283
#10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801
#11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916
#12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 18, 2021
When running device-introspect-test, a memory leak occurred in the mos6522_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 96 byte(s) in 2 object(s) allocated from:
#0 0xfffd5fe9e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xfffd5f7b6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaae50303d0c in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaae50303d0c in timer_new qemu/include/qemu/timer.h:544
#4 0xaaae50303d0c in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaae50303d0c in mos6522_init qemu/hw/misc/mos6522.c:490
#6 0xaaae50b77d70 in object_init_with_type qemu/qom/object.c:371
#7 0xaaae50b7ae84 in object_initialize_with_type qemu/qom/object.c:515
#8 0xaaae50b7b0f8 in object_new_with_type qemu/qom/object.c:729
#9 0xaaae50bb6d58 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#10 0xaaae50d7e1dc in qmp_marshal_device_list_properties qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaae50dc87a0 in do_qmp_dispatch_bh qemu/qapi/qmp-dispatch.c:110
#12 0xaaae50d931a0 in aio_bh_call qemu/util/async.c:136
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Acked-by: David Gibson <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 19, 2021
The adc_qom_set function didn't free "response", which caused an indirect
memory leak. So use qobject_unref() to fix it.
ASAN shows memory leak stack:
Indirect leak of 593280 byte(s) in 144 object(s) allocated from:
#0 0x7f9a5e7e8d4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e)
#1 0x7f9a5e607a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50)
#2 0x55b1bebf636b in qdict_new ../qobject/qdict.c:30
#3 0x55b1bec09699 in parse_object ../qobject/json-parser.c:318
#4 0x55b1bec0b2df in parse_value ../qobject/json-parser.c:546
#5 0x55b1bec0b6a9 in json_parser_parse ../qobject/json-parser.c:580
#6 0x55b1bec060d1 in json_message_process_token ../qobject/json-streamer.c:92
#7 0x55b1bec16a12 in json_lexer_feed_char ../qobject/json-lexer.c:313
#8 0x55b1bec16fbd in json_lexer_feed ../qobject/json-lexer.c:350
#9 0x55b1bec06453 in json_message_parser_feed ../qobject/json-streamer.c:121
#10 0x55b1bebc2d51 in qmp_fd_receive ../tests/qtest/libqtest.c:614
#11 0x55b1bebc2f5e in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636
#12 0x55b1bebc2e6c in qtest_qmp_receive ../tests/qtest/libqtest.c:624
#13 0x55b1bebc3340 in qtest_vqmp ../tests/qtest/libqtest.c:715
#14 0x55b1bebc3942 in qtest_qmp ../tests/qtest/libqtest.c:756
#15 0x55b1bebbd64a in adc_qom_set ../tests/qtest/npcm7xx_adc-test.c:127
#16 0x55b1bebbd793 in adc_write_input ../tests/qtest/npcm7xx_adc-test.c:140
#17 0x55b1bebbdf92 in test_convert_external ../tests/qtest/npcm7xx_adc-test.c:246
Reported-by: Euler Robot <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Hao Wu <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 21, 2021
The pwm_qom_get function didn't free "response", which caused an indirect
memory leak. So use qobject_unref() to fix it.
ASAN shows memory leak stack:
Indirect leak of 74160000 byte(s) in 18000 object(s) allocated from:
#0 0x7f96e2f79d4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e)
#1 0x7f96e2d98a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50)
#2 0x556313112180 in qdict_new ../qobject/qdict.c:30
#3 0x556313115bca in parse_object ../qobject/json-parser.c:318
#4 0x556313117810 in parse_value ../qobject/json-parser.c:546
#5 0x556313117bda in json_parser_parse ../qobject/json-parser.c:580
#6 0x55631310fe67 in json_message_process_token ../qobject/json-streamer.c:92
#7 0x5563131210b7 in json_lexer_feed_char ../qobject/json-lexer.c:313
#8 0x556313121662 in json_lexer_feed ../qobject/json-lexer.c:350
#9 0x5563131101e9 in json_message_parser_feed ../qobject/json-streamer.c:121
#10 0x5563130cb81e in qmp_fd_receive ../tests/qtest/libqtest.c:614
#11 0x5563130cba2b in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636
#12 0x5563130cb939 in qtest_qmp_receive ../tests/qtest/libqtest.c:624
#13 0x5563130cbe0d in qtest_vqmp ../tests/qtest/libqtest.c:715
#14 0x5563130cc40f in qtest_qmp ../tests/qtest/libqtest.c:756
#15 0x5563130c5623 in pwm_qom_get ../tests/qtest/npcm7xx_pwm-test.c:180
#16 0x5563130c595e in pwm_get_duty ../tests/qtest/npcm7xx_pwm-test.c:210
#17 0x5563130c7529 in test_toggle ../tests/qtest/npcm7xx_pwm-test.c:447
Reported-by: Euler Robot <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Gan Qixin <[email protected]>
Reviewed-by: Havard Skinnemoen <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Hao Wu <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 21, 2021
This patch fixes the following memory leak detected by asan:
Indirect leak of 560320 byte(s) in 136 object(s) allocated from:
#0 0x556b3b3f9b57 in calloc (/home/stefanb/tmp/qemu-tip/build/tests/qtest/tpm-crb-swtpm-test+0x23fb57)
#1 0x152b0e96b9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0)
#2 0x556b3b588f61 in parse_object /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:318:12
#3 0x556b3b588f61 in parse_value /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:546:16
#4 0x556b3b5886e8 in json_parser_parse /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:580:14
#5 0x556b3b52ff4a in json_message_process_token /home/stefanb/tmp/qemu-tip/build/../qobject/json-streamer.c:92:12
#6 0x556b3b59896f in json_lexer_feed_char /home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:313:13
#7 0x556b3b598443 in json_lexer_feed /home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:350:9
#8 0x556b3b436c70 in qmp_fd_receive /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:614:9
#9 0x556b3b435871 in qtest_qmp_receive_dict /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:636:12
#10 0x556b3b435871 in qtest_qmp_receive /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:624:27
#11 0x556b3b435c59 in qtest_vqmp /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:715:12
#12 0x556b3b435c59 in qtest_qmp /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:756:16
#13 0x556b3b4328c7 in tpm_util_wait_for_migration_complete /home/stefanb/tmp/qemu-tip/build/../tests/qtest/tpm-util.c:245:15
#14 0x556b3b4333be in tpm_test_swtpm_migration_test /home/stefanb/tmp/qemu-tip/build/../tests/qtest/tpm-tests.c:117:5
#15 0x152b0e98e29d (/lib64/libglib-2.0.so.0+0x7b29d)
Signed-off-by: Stefan Berger <[email protected]>
Cc: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jan 24, 2021
There are two cases that need to be accounted for when compiling QEMU
for MinGW32:
1) A standalone distribution, where QEMU is self contained and
extracted by the user, such as a user would download from the QEMU
website. In this case, all the QEMU executable files should be
rooted in $prefix to ensure they can be easily found by the user
2) QEMU integrated into a distribution image/sysroot/SDK and
distributed with other programs. In this case, the provided
arguments for bindir/datadir/etc. should be respected as they for a
Linux build.
Restructures the MinGW path configuration so that all of the paths
except bindir use the same rules as when building for other platforms.
This satisfies #2 and #1 since these files do not need to be directly in
$prefix anyway.
The handling for --bindir is changed so that it defaults to $prefix on
MinGW (maintaining the compatibility with #1), but if the user specifies
a specific path when configuring it can also satisfy #2.
Signed-off-by: Joshua Watt <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Feb 3, 2021
Alexander reported an issue in gic_get_current_cpu() using the
fuzzer. Yet another "deref current_cpu with QTest" bug, reproducible
doing:
$ echo readb 0xf03ff000 | qemu-system-arm -M npcm750-evb,accel=qtest -qtest stdio
[I 1611849440.651452] OPENED
[R +0.242498] readb 0xf03ff000
hw/intc/arm_gic.c:63:29: runtime error: member access within null pointer of type 'CPUState' (aka 'struct CPUState')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior hw/intc/arm_gic.c:63:29 in
AddressSanitizer:DEADLYSIGNAL
=================================================================
==3719691==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000082a0 (pc 0x5618790ac882 bp 0x7ffca946f4f0 sp 0x7ffca946f4a0 T0)
==3719691==The signal is caused by a READ memory access.
#0 0x5618790ac882 in gic_get_current_cpu hw/intc/arm_gic.c:63:29
#1 0x5618790a8901 in gic_dist_readb hw/intc/arm_gic.c:955:11
#2 0x5618790a7489 in gic_dist_read hw/intc/arm_gic.c:1158:17
#3 0x56187adc573b in memory_region_read_with_attrs_accessor softmmu/memory.c:464:9
#4 0x56187ad7903a in access_with_adjusted_size softmmu/memory.c:552:18
#5 0x56187ad766d6 in memory_region_dispatch_read1 softmmu/memory.c:1426:16
#6 0x56187ad758a8 in memory_region_dispatch_read softmmu/memory.c:1449:9
#7 0x56187b09e84c in flatview_read_continue softmmu/physmem.c:2822:23
#8 0x56187b0a0115 in flatview_read softmmu/physmem.c:2862:12
#9 0x56187b09fc9e in address_space_read_full softmmu/physmem.c:2875:18
#10 0x56187aa88633 in address_space_read include/exec/memory.h:2489:18
#11 0x56187aa88633 in qtest_process_command softmmu/qtest.c:558:13
#12 0x56187aa81881 in qtest_process_inbuf softmmu/qtest.c:797:9
#13 0x56187aa80e02 in qtest_read softmmu/qtest.c:809:5
current_cpu is NULL because QTest accelerator does not use CPU.
Fix by skipping the check and returning the first CPU index when
QTest accelerator is used, similarly to commit c781a2c
("hw/i386/vmport: Allow QTest use without crashing").
Reported-by: Alexander Bulekov <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Darren Kenny <[email protected]>
Reviewed-by: Alexander Bulekov <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Feb 3, 2021
When the reconnect in NBD client is in progress, the iochannel used for
NBD connection doesn't exist. Therefore an attempt to detach it from
the aio_context of the parent BlockDriverState results in a NULL pointer
dereference.
The problem is triggerable, in particular, when an outgoing migration is
about to finish, and stopping the dataplane tries to move the
BlockDriverState from the iothread aio_context to the main loop. If the
NBD connection is lost before this point, and the NBD client has entered
the reconnect procedure, QEMU crashes:
#0 qemu_aio_coroutine_enter (ctx=0x5618056c7580, co=0x0)
at /build/qemu-6MF7tq/qemu-5.0.1/util/qemu-coroutine.c:109
#1 0x00005618034b1b68 in nbd_client_attach_aio_context_bh (
opaque=0x561805ed4c00) at /build/qemu-6MF7tq/qemu-5.0.1/block/nbd.c:164
#2 0x000056180353116b in aio_wait_bh (opaque=0x7f60e1e63700)
at /build/qemu-6MF7tq/qemu-5.0.1/util/aio-wait.c:55
#3 0x0000561803530633 in aio_bh_call (bh=0x7f60d40a7e80)
at /build/qemu-6MF7tq/qemu-5.0.1/util/async.c:136
#4 aio_bh_poll (ctx=ctx@entry=0x5618056c7580)
at /build/qemu-6MF7tq/qemu-5.0.1/util/async.c:164
#5 0x0000561803533e5a in aio_poll (ctx=ctx@entry=0x5618056c7580,
blocking=blocking@entry=true)
at /build/qemu-6MF7tq/qemu-5.0.1/util/aio-posix.c:650
#6 0x000056180353128d in aio_wait_bh_oneshot (ctx=0x5618056c7580,
cb=<optimized out>, opaque=<optimized out>)
at /build/qemu-6MF7tq/qemu-5.0.1/util/aio-wait.c:71
#7 0x000056180345c50a in bdrv_attach_aio_context (new_context=0x5618056c7580,
bs=0x561805ed4c00) at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6172
#8 bdrv_set_aio_context_ignore (bs=bs@entry=0x561805ed4c00,
new_context=new_context@entry=0x5618056c7580,
ignore=ignore@entry=0x7f60e1e63780)
at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6237
#9 0x000056180345c969 in bdrv_child_try_set_aio_context (
bs=bs@entry=0x561805ed4c00, ctx=0x5618056c7580,
ignore_child=<optimized out>, errp=<optimized out>)
at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6332
#10 0x00005618034957db in blk_do_set_aio_context (blk=0x56180695b3f0,
new_context=0x5618056c7580, update_root_node=update_root_node@entry=true,
errp=errp@entry=0x0)
at /build/qemu-6MF7tq/qemu-5.0.1/block/block-backend.c:1989
#11 0x00005618034980bd in blk_set_aio_context (blk=<optimized out>,
new_context=<optimized out>, errp=errp@entry=0x0)
at /build/qemu-6MF7tq/qemu-5.0.1/block/block-backend.c:2010
#12 0x0000561803197953 in virtio_blk_data_plane_stop (vdev=<optimized out>)
at /build/qemu-6MF7tq/qemu-5.0.1/hw/block/dataplane/virtio-blk.c:292
#13 0x00005618033d67bf in virtio_bus_stop_ioeventfd (bus=0x5618056d9f08)
at /build/qemu-6MF7tq/qemu-5.0.1/hw/virtio/virtio-bus.c:245
#14 0x00005618031c9b2e in virtio_vmstate_change (opaque=0x5618056d9f90,
running=0, state=<optimized out>)
at /build/qemu-6MF7tq/qemu-5.0.1/hw/virtio/virtio.c:3220
#15 0x0000561803208bfd in vm_state_notify (running=running@entry=0,
state=state@entry=RUN_STATE_FINISH_MIGRATE)
at /build/qemu-6MF7tq/qemu-5.0.1/softmmu/vl.c:1275
#16 0x0000561803155c02 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE,
send_stop=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/cpus.c:1032
#17 0x00005618033e3765 in migration_completion (s=0x5618056e6960)
at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:2914
#18 migration_iteration_run (s=0x5618056e6960)
at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:3275
#19 migration_thread (opaque=opaque@entry=0x5618056e6960)
at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:3439
#20 0x0000561803536ad6 in qemu_thread_start (args=<optimized out>)
at /build/qemu-6MF7tq/qemu-5.0.1/util/qemu-thread-posix.c:519
#21 0x00007f61085d06ba in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#22 0x00007f610830641d in sysctl () from /lib/x86_64-linux-gnu/libc.so.6
#23 0x0000000000000000 in ?? ()
Fix it by checking that the iochannel is non-null before trying to
detach it from the aio_context. If it is null, no detaching is needed,
and it will get reattached in the proper aio_context once the connection
is reestablished.
Signed-off-by: Roman Kagan <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Eric Blake <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Feb 3, 2021
When an NBD block driver state is moved from one aio_context to another
(e.g. when doing a drain in a migration thread),
nbd_client_attach_aio_context_bh is executed that enters the connection
coroutine.
However, the assumption that ->connection_co is always present here
appears incorrect: the connection may have encountered an error other
than -EIO in the underlying transport, and thus may have decided to quit
rather than keep trying to reconnect, and therefore it may have
terminated the connection coroutine. As a result an attempt to reassign
the client in this state (NBD_CLIENT_QUIT) to a different aio_context
leads to a null pointer dereference:
#0 qio_channel_detach_aio_context (ioc=0x0)
at /build/qemu-gYtjVn/qemu-5.0.1/io/channel.c:452
#1 0x0000562a242824b3 in bdrv_detach_aio_context (bs=0x562a268d6a00)
at /build/qemu-gYtjVn/qemu-5.0.1/block.c:6151
#2 bdrv_set_aio_context_ignore (bs=bs@entry=0x562a268d6a00,
new_context=new_context@entry=0x562a260c9580,
ignore=ignore@entry=0x7feeadc9b780)
at /build/qemu-gYtjVn/qemu-5.0.1/block.c:6230
#3 0x0000562a24282969 in bdrv_child_try_set_aio_context
(bs=bs@entry=0x562a268d6a00, ctx=0x562a260c9580,
ignore_child=<optimized out>, errp=<optimized out>)
at /build/qemu-gYtjVn/qemu-5.0.1/block.c:6332
#4 0x0000562a242bb7db in blk_do_set_aio_context (blk=0x562a2735d0d0,
new_context=0x562a260c9580,
update_root_node=update_root_node@entry=true, errp=errp@entry=0x0)
at /build/qemu-gYtjVn/qemu-5.0.1/block/block-backend.c:1989
#5 0x0000562a242be0bd in blk_set_aio_context (blk=<optimized out>,
new_context=<optimized out>, errp=errp@entry=0x0)
at /build/qemu-gYtjVn/qemu-5.0.1/block/block-backend.c:2010
#6 0x0000562a23fbd953 in virtio_blk_data_plane_stop (vdev=<optimized
out>)
at /build/qemu-gYtjVn/qemu-5.0.1/hw/block/dataplane/virtio-blk.c:292
#7 0x0000562a241fc7bf in virtio_bus_stop_ioeventfd (bus=0x562a260dbf08)
at /build/qemu-gYtjVn/qemu-5.0.1/hw/virtio/virtio-bus.c:245
#8 0x0000562a23fefb2e in virtio_vmstate_change (opaque=0x562a260dbf90,
running=0, state=<optimized out>)
at /build/qemu-gYtjVn/qemu-5.0.1/hw/virtio/virtio.c:3220
#9 0x0000562a2402ebfd in vm_state_notify (running=running@entry=0,
state=state@entry=RUN_STATE_FINISH_MIGRATE)
at /build/qemu-gYtjVn/qemu-5.0.1/softmmu/vl.c:1275
#10 0x0000562a23f7bc02 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE,
send_stop=<optimized out>)
at /build/qemu-gYtjVn/qemu-5.0.1/cpus.c:1032
#11 0x0000562a24209765 in migration_completion (s=0x562a260e83a0)
at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:2914
#12 migration_iteration_run (s=0x562a260e83a0)
at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:3275
#13 migration_thread (opaque=opaque@entry=0x562a260e83a0)
at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:3439
#14 0x0000562a2435ca96 in qemu_thread_start (args=<optimized out>)
at /build/qemu-gYtjVn/qemu-5.0.1/util/qemu-thread-posix.c:519
#15 0x00007feed31466ba in start_thread (arg=0x7feeadc9c700)
at pthread_create.c:333
#16 0x00007feed2e7c41d in __GI___sysctl (name=0x0, nlen=608471908,
oldval=0x562a2452b138, oldlenp=0x0, newval=0x562a2452c5e0
<__func__.28102>, newlen=0)
at ../sysdeps/unix/sysv/linux/sysctl.c:30
#17 0x0000000000000000 in ?? ()
Fix it by checking that the connection coroutine is non-null before
trying to enter it. If it is null, no entering is needed, as the
connection is probably going down anyway.
Signed-off-by: Roman Kagan <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Eric Blake <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Feb 5, 2021
Address space is destroyed without proper removal of its listeners with
current code. They are expected to be removed in
virtio_device_instance_finalize [1], but qemu calls it through
object_deinit, after address_space_destroy call through
device_set_realized [2].
Move it to virtio_device_unrealize, called before device_set_realized
[3] and making it symmetric with memory_listener_register in
virtio_device_realize.
v2: Delete no-op call of virtio_device_instance_finalize.
Add backtraces.
[1]
#0 virtio_device_instance_finalize (obj=0x555557de5120)
at /home/qemu/include/hw/virtio/virtio.h:71
#1 0x0000555555b703c9 in object_deinit (type=0x555556639860,
obj=<optimized out>) at ../qom/object.c:671
#2 object_finalize (data=0x555557de5120) at ../qom/object.c:685
#3 object_unref (objptr=0x555557de5120) at ../qom/object.c:1184
#4 0x0000555555b4de9d in bus_free_bus_child (kid=0x555557df0660)
at ../hw/core/qdev.c:55
#5 0x0000555555c65003 in call_rcu_thread (opaque=opaque@entry=0x0)
at ../util/rcu.c:281
Queued by:
#0 bus_remove_child (bus=0x555557de5098,
child=child@entry=0x555557de5120) at ../hw/core/qdev.c:60
#1 0x0000555555b4ee31 in device_unparent (obj=<optimized out>)
at ../hw/core/qdev.c:984
#2 0x0000555555b70465 in object_finalize_child_property (
obj=<optimized out>, name=<optimized out>, opaque=0x555557de5120)
at ../qom/object.c:1725
#3 0x0000555555b6fa17 in object_property_del_child (
child=0x555557de5120, obj=0x555557ddcf90) at ../qom/object.c:645
#4 object_unparent (obj=0x555557de5120) at ../qom/object.c:664
#5 0x0000555555b4c071 in bus_unparent (obj=<optimized out>)
at ../hw/core/bus.c:147
#6 0x0000555555b70465 in object_finalize_child_property (
obj=<optimized out>, name=<optimized out>, opaque=0x555557de5098)
at ../qom/object.c:1725
#7 0x0000555555b6fa17 in object_property_del_child (
child=0x555557de5098, obj=0x555557ddcf90) at ../qom/object.c:645
#8 object_unparent (obj=0x555557de5098) at ../qom/object.c:664
#9 0x0000555555b4ee19 in device_unparent (obj=<optimized out>)
at ../hw/core/qdev.c:981
#10 0x0000555555b70465 in object_finalize_child_property (
obj=<optimized out>, name=<optimized out>, opaque=0x555557ddcf90)
at ../qom/object.c:1725
#11 0x0000555555b6fa17 in object_property_del_child (
child=0x555557ddcf90, obj=0x55555685da10) at ../qom/object.c:645
#12 object_unparent (obj=0x555557ddcf90) at ../qom/object.c:664
#13 0x00005555558dc331 in pci_for_each_device_under_bus (
opaque=<optimized out>, fn=<optimized out>, bus=<optimized out>)
at ../hw/pci/pci.c:1654
[2]
Optimizer omits pci_qdev_unrealize, called by device_set_realized, and
do_pci_unregister_device, called by pci_qdev_unrealize and caller of
address_space_destroy.
#0 address_space_destroy (as=0x555557ddd1b8)
at ../softmmu/memory.c:2840
#1 0x0000555555b4fc53 in device_set_realized (obj=0x555557ddcf90,
value=<optimized out>, errp=0x7fffeea8f1e0)
at ../hw/core/qdev.c:850
#2 0x0000555555b6eaa6 in property_set_bool (obj=0x555557ddcf90,
v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0,
errp=0x7fffeea8f1e0) at ../qom/object.c:2255
#3 0x0000555555b70e07 in object_property_set (
obj=obj@entry=0x555557ddcf90,
name=name@entry=0x555555db99df "realized",
v=v@entry=0x7fffe46b7500,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1400
#4 0x0000555555b73c5f in object_property_set_qobject (
obj=obj@entry=0x555557ddcf90,
name=name@entry=0x555555db99df "realized",
value=value@entry=0x7fffe44f6180,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/qom-qobject.c:28
#5 0x0000555555b71044 in object_property_set_bool (
obj=0x555557ddcf90, name=0x555555db99df "realized",
value=<optimized out>, errp=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1470
#6 0x0000555555921cb7 in pcie_unplug_device (bus=<optimized out>,
dev=0x555557ddcf90,
opaque=<optimized out>) at /home/qemu/include/hw/qdev-core.h:17
#7 0x00005555558dc331 in pci_for_each_device_under_bus (
opaque=<optimized out>, fn=<optimized out>,
bus=<optimized out>) at ../hw/pci/pci.c:1654
[3]
#0 virtio_device_unrealize (dev=0x555557de5120)
at ../hw/virtio/virtio.c:3680
#1 0x0000555555b4fc63 in device_set_realized (obj=0x555557de5120,
value=<optimized out>, errp=0x7fffee28df90)
at ../hw/core/qdev.c:850
#2 0x0000555555b6eab6 in property_set_bool (obj=0x555557de5120,
v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0,
errp=0x7fffee28df90) at ../qom/object.c:2255
#3 0x0000555555b70e17 in object_property_set (
obj=obj@entry=0x555557de5120,
name=name@entry=0x555555db99ff "realized",
v=v@entry=0x7ffdd8035040,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1400
#4 0x0000555555b73c6f in object_property_set_qobject (
obj=obj@entry=0x555557de5120,
name=name@entry=0x555555db99ff "realized",
value=value@entry=0x7ffdd8035020,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/qom-qobject.c:28
#5 0x0000555555b71054 in object_property_set_bool (
obj=0x555557de5120, name=name@entry=0x555555db99ff "realized",
value=value@entry=false, errp=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1470
#6 0x0000555555b4edc5 in qdev_unrealize (dev=<optimized out>)
at ../hw/core/qdev.c:403
#7 0x0000555555b4c2a9 in bus_set_realized (obj=<optimized out>,
value=<optimized out>, errp=<optimized out>)
at ../hw/core/bus.c:204
#8 0x0000555555b6eab6 in property_set_bool (obj=0x555557de5098,
v=<optimized out>, name=<optimized out>, opaque=0x555557df04c0,
errp=0x7fffee28e0a0) at ../qom/object.c:2255
#9 0x0000555555b70e17 in object_property_set (
obj=obj@entry=0x555557de5098,
name=name@entry=0x555555db99ff "realized",
v=v@entry=0x7ffdd8034f50,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1400
#10 0x0000555555b73c6f in object_property_set_qobject (
obj=obj@entry=0x555557de5098,
name=name@entry=0x555555db99ff "realized",
value=value@entry=0x7ffdd8020630,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/qom-qobject.c:28
#11 0x0000555555b71054 in object_property_set_bool (
obj=obj@entry=0x555557de5098,
name=name@entry=0x555555db99ff "realized",
value=value@entry=false, errp=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1470
#12 0x0000555555b4c725 in qbus_unrealize (
bus=bus@entry=0x555557de5098) at ../hw/core/bus.c:178
#13 0x0000555555b4fc00 in device_set_realized (obj=0x555557ddcf90,
value=<optimized out>, errp=0x7fffee28e1e0)
at ../hw/core/qdev.c:844
#14 0x0000555555b6eab6 in property_set_bool (obj=0x555557ddcf90,
v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0,
errp=0x7fffee28e1e0) at ../qom/object.c:2255
#15 0x0000555555b70e17 in object_property_set (
obj=obj@entry=0x555557ddcf90,
name=name@entry=0x555555db99ff "realized",
v=v@entry=0x7ffdd8020560,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1400
#16 0x0000555555b73c6f in object_property_set_qobject (
obj=obj@entry=0x555557ddcf90,
name=name@entry=0x555555db99ff "realized",
value=value@entry=0x7ffdd8020540,
errp=errp@entry=0x5555565bbf38 <error_abort>)
at ../qom/qom-qobject.c:28
#17 0x0000555555b71054 in object_property_set_bool (
obj=0x555557ddcf90, name=0x555555db99ff "realized",
value=<optimized out>, errp=0x5555565bbf38 <error_abort>)
at ../qom/object.c:1470
#18 0x0000555555921cb7 in pcie_unplug_device (bus=<optimized out>,
dev=0x555557ddcf90, opaque=<optimized out>)
at /home/qemu/include/hw/qdev-core.h:17
#19 0x00005555558dc331 in pci_for_each_device_under_bus (
opaque=<optimized out>, fn=<optimized out>, bus=<optimized out>)
at ../hw/pci/pci.c:1654
Fixes: c611c76 ("virtio: add MemoryListener to cache ring translations")
Buglink: https://bugs.launchpad.net/qemu/+bug/1912846
Signed-off-by: Eugenio Pérez <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Acked-by: Jason Wang <[email protected]>
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Feb 5, 2021
Not checking this can lead to invalid dev->vdev member access in
vhost_device_iotlb_miss if backend issue an iotlb message in a bad
timing, either maliciously or by a bug.
Reproduced rebooting a guest with testpmd in txonly forward mode.
#0 0x0000559ffff94394 in vhost_device_iotlb_miss (
dev=dev@entry=0x55a0012f6680, iova=10245279744, write=1)
at ../hw/virtio/vhost.c:1013
#1 0x0000559ffff9ac31 in vhost_backend_handle_iotlb_msg (
imsg=0x7ffddcfd32c0, dev=0x55a0012f6680)
at ../hw/virtio/vhost-backend.c:411
#2 vhost_backend_handle_iotlb_msg (dev=dev@entry=0x55a0012f6680,
imsg=imsg@entry=0x7ffddcfd32c0)
at ../hw/virtio/vhost-backend.c:404
#3 0x0000559fffeded7b in slave_read (opaque=0x55a0012f6680)
at ../hw/virtio/vhost-user.c:1464
#4 0x000055a0000c541b in aio_dispatch_handler (
ctx=ctx@entry=0x55a0010a2120, node=0x55a0012d9e00)
at ../util/aio-posix.c:329
Fixes: 020e571 ("vhost: rework IOTLB messaging")
Signed-off-by: Eugenio Pérez <[email protected]>
Message-Id: <[email protected]>
Acked-by: Jason Wang <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Mar 8, 2021
Commit v5.2.0-190-g0546c0609c ("vl: split various early command line
options to a separate function") moved the trace backend init code to
the qemu_process_early_options(). Which is now being called before
os_daemonize() via qemu_maybe_daemonize().
Turns out that this change of order causes a problem when executing
QEMU in daemon mode and with CONFIG_TRACE_SIMPLE. The trace thread
is now being created by the parent, and the parent is left waiting for
a trace file flush that was registered via st_init(). The result is
that the parent process never exits.
To reproduce, fire up a QEMU process with -daemonize and with
CONFIG_TRACE_SIMPLE enabled. Two QEMU process will be left in the
host:
$ sudo ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults \
-nographic -machine none,accel=kvm:tcg -daemonize
$ ps axf | grep qemu
529710 pts/3 S+ 0:00 | \_ grep --color=auto qemu
529697 ? Ssl 0:00 \_ ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize
529699 ? Sl 0:00 \_ ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize
The parent thread is hang in flush_trace_file:
$ sudo gdb ./x86_64-softmmu/qemu-system-x86_64 529697
(..)
(gdb) bt
#0 0x00007f9dac6a137d in syscall () at /lib64/libc.so.6
#1 0x00007f9dacc3c4f3 in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x0000555d12f952da in flush_trace_file (wait=true) at ../trace/simple.c:140
#3 0x0000555d12f95b4c in st_flush_trace_buffer () at ../trace/simple.c:383
#4 0x00007f9dac5e43a7 in __run_exit_handlers () at /lib64/libc.so.6
#5 0x00007f9dac5e4550 in on_exit () at /lib64/libc.so.6
#6 0x0000555d12d454de in os_daemonize () at ../os-posix.c:255
#7 0x0000555d12d0bd5c in qemu_maybe_daemonize (pid_file=0x0) at ../softmmu/vl.c:2408
#8 0x0000555d12d0e566 in qemu_init (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/vl.c:3459
#9 0x0000555d128edac1 in main (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/main.c:49
(gdb)
Aside from the 'zombie' process in the host, this is directly impacting
Libvirt. Libvirt waits for the parent process to exit to be sure that the
QMP monitor is available in the daemonized process to fetch QEMU
capabilities, and as is now Libvirt hangs at daemon start waiting
for the parent thread to exit.
The fix is simple: just move the trace backend related code back to
be executed after daemonizing.
Fixes: 0546c06
Reviewed-by: Paolo Bonzini <[email protected]>
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Message-Id: <[email protected]>
Acked-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Mar 22, 2021
We can't know the caller read enough data in the memory pointed
by ext_hdr to cast it as a ip6_ext_hdr_routing.
Declare rt_hdr on the stack and fill it again from the iovec.
Since we already checked there is enough data in the iovec buffer,
simply add an assert() call to consume the bytes_read variable.
This fix a 2 bytes buffer overrun in eth_parse_ipv6_hdr() reported
by QEMU fuzzer:
$ cat << EOF | ./qemu-system-i386 -M pc-q35-5.0 \
-accel qtest -monitor none \
-serial none -nographic -qtest stdio
outl 0xcf8 0x80001010
outl 0xcfc 0xe1020000
outl 0xcf8 0x80001004
outw 0xcfc 0x7
write 0x25 0x1 0x86
write 0x26 0x1 0xdd
write 0x4f 0x1 0x2b
write 0xe1020030 0x4 0x190002e1
write 0xe102003a 0x2 0x0807
write 0xe1020048 0x4 0x12077cdd
write 0xe1020400 0x4 0xba077cdd
write 0xe1020420 0x4 0x190002e1
write 0xe1020428 0x4 0x3509d807
write 0xe1020438 0x1 0xe2
EOF
=================================================================
==2859770==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdef904902 at pc 0x561ceefa78de bp 0x7ffdef904820 sp 0x7ffdef904818
READ of size 1 at 0x7ffdef904902 thread T0
#0 0x561ceefa78dd in _eth_get_rss_ex_dst_addr net/eth.c:410:17
#1 0x561ceefa41fb in eth_parse_ipv6_hdr net/eth.c:532:17
#2 0x561cef7de639 in net_tx_pkt_parse_headers hw/net/net_tx_pkt.c:228:14
#3 0x561cef7dbef4 in net_tx_pkt_parse hw/net/net_tx_pkt.c:273:9
#4 0x561ceec29f22 in e1000e_process_tx_desc hw/net/e1000e_core.c:730:29
#5 0x561ceec28eac in e1000e_start_xmit hw/net/e1000e_core.c:927:9
#6 0x561ceec1baab in e1000e_set_tdt hw/net/e1000e_core.c:2444:9
#7 0x561ceebf300e in e1000e_core_write hw/net/e1000e_core.c:3256:9
#8 0x561cef3cd4cd in e1000e_mmio_write hw/net/e1000e.c:110:5
Address 0x7ffdef904902 is located in stack of thread T0 at offset 34 in frame
#0 0x561ceefa320f in eth_parse_ipv6_hdr net/eth.c:486
This frame has 1 object(s):
[32, 34) 'ext_hdr' (line 487) <== Memory access at offset 34 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow net/eth.c:410:17 in _eth_get_rss_ex_dst_addr
Shadow bytes around the buggy address:
0x10003df188d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df188e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df188f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18910: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x10003df18920:[02]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10003df18970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Stack left redzone: f1
Stack right redzone: f3
==2859770==ABORTING
Add the corresponding qtest case with the fuzzer reproducer.
FWIW GCC 11 similarly reported:
net/eth.c: In function 'eth_parse_ipv6_hdr':
net/eth.c:410:15: error: array subscript 'struct ip6_ext_hdr_routing[0]' is partly outside array bounds of 'struct ip6_ext_hdr[1]' [-Werror=array-bounds]
410 | if ((rthdr->rtype == 2) && (rthdr->segleft == 1)) {
| ~~~~~^~~~~~~
net/eth.c:485:24: note: while referencing 'ext_hdr'
485 | struct ip6_ext_hdr ext_hdr;
| ^~~~~~~
net/eth.c:410:38: error: array subscript 'struct ip6_ext_hdr_routing[0]' is partly outside array bounds of 'struct ip6_ext_hdr[1]' [-Werror=array-bounds]
410 | if ((rthdr->rtype == 2) && (rthdr->segleft == 1)) {
| ~~~~~^~~~~~~~~
net/eth.c:485:24: note: while referencing 'ext_hdr'
485 | struct ip6_ext_hdr ext_hdr;
| ^~~~~~~
Cc: [email protected]
Buglink: https://bugs.launchpad.net/qemu/+bug/1879531
Reported-by: Alexander Bulekov <[email protected]>
Reported-by: Miroslav Rezanina <[email protected]>
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Miroslav Rezanina <[email protected]>
Fixes: eb70002 ("net_pkt: Extend packet abstraction as required by e1000e functionality")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Mar 26, 2021
Incoming enabled bitmaps are busy, because we do bdrv_dirty_bitmap_create_successor() for them. But disabled bitmaps being migrated are not marked busy, and user can remove them during the incoming migration. Then we may crash in cancel_incoming_locked() when try to remove the bitmap that was already removed by user, like this: #0 qemu_mutex_lock_impl (mutex=0x5593d88c50d1, file=0x559680554b20 "../block/dirty-bitmap.c", line=64) at ../util/qemu-thread-posix.c:77 #1 bdrv_dirty_bitmaps_lock (bs=0x5593d88c0ee9) at ../block/dirty-bitmap.c:64 #2 bdrv_release_dirty_bitmap (bitmap=0x5596810e9570) at ../block/dirty-bitmap.c:362 #3 cancel_incoming_locked (s=0x559680be8208 <dbm_state+40>) at ../migration/block-dirty-bitmap.c:918 #4 dirty_bitmap_load (f=0x559681d02b10, opaque=0x559680be81e0 <dbm_state>, version_id=1) at ../migration/block-dirty-bitmap.c:1194 #5 vmstate_load (f=0x559681d02b10, se=0x559680fb5810) at ../migration/savevm.c:908 #6 qemu_loadvm_section_part_end (f=0x559681d02b10, mis=0x559680fb4a30) at ../migration/savevm.c:2473 #7 qemu_loadvm_state_main (f=0x559681d02b10, mis=0x559680fb4a30) at ../migration/savevm.c:2626 #8 postcopy_ram_listen_thread (opaque=0x0) at ../migration/savevm.c:1871 #9 qemu_thread_start (args=0x5596817ccd10) at ../util/qemu-thread-posix.c:521 #10 start_thread () at /lib64/libpthread.so.0 #11 clone () at /lib64/libc.so.6 Note bs pointer taken from bitmap: it's definitely bad aligned. That's because we are in use after free, bitmap is already freed. So, let's make disabled bitmaps (being migrated) busy during incoming migration. Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Mar 26, 2021
When building with --enable-sanitizers we get:
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0x5618479ec7cf in malloc (qemu-system-aarch64+0x233b7cf)
#1 0x7f675745f958 in g_malloc (/lib64/libglib-2.0.so.0+0x58958)
#2 0x561847f02ca2 in usb_packet_init hw/usb/core.c:531:5
#3 0x561848df4df4 in usb_ehci_init hw/usb/hcd-ehci.c:2575:5
#4 0x561847c119ac in ehci_sysbus_init hw/usb/hcd-ehci-sysbus.c:73:5
#5 0x56184a5bdab8 in object_init_with_type qom/object.c:375:9
#6 0x56184a5bd955 in object_init_with_type qom/object.c:371:9
#7 0x56184a5a2bda in object_initialize_with_type qom/object.c:517:5
#8 0x56184a5a24d5 in object_initialize qom/object.c:536:5
#9 0x56184a5a2f6c in object_initialize_child_with_propsv qom/object.c:566:5
#10 0x56184a5a2e60 in object_initialize_child_with_props qom/object.c:549:10
#11 0x56184a5a3a1e in object_initialize_child_internal qom/object.c:603:5
#12 0x561849542d18 in npcm7xx_init hw/arm/npcm7xx.c:427:5
Similarly to commit d710e1e ("usb: ehci: fix memory leak in
ehci"), fix by calling usb_ehci_finalize() to free the USBPacket.
Fixes: 7341ea0
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Mar 30, 2021
When building with --enable-sanitizers we get:
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x5618479ec7cf in malloc (qemu-system-aarch64+0x233b7cf)
#1 0x7f675745f958 in g_malloc (/lib64/libglib-2.0.so.0+0x58958)
#2 0x561847c2dcc9 in xlnx_dp_init hw/display/xlnx_dp.c:1259:5
#3 0x56184a5bdab8 in object_init_with_type qom/object.c:375:9
#4 0x56184a5a2bda in object_initialize_with_type qom/object.c:517:5
#5 0x56184a5a24d5 in object_initialize qom/object.c:536:5
#6 0x56184a5a2f6c in object_initialize_child_with_propsv qom/object.c:566:5
#7 0x56184a5a2e60 in object_initialize_child_with_props qom/object.c:549:10
#8 0x56184a5a3a1e in object_initialize_child_internal qom/object.c:603:5
#9 0x5618495aa431 in xlnx_zynqmp_init hw/arm/xlnx-zynqmp.c:273:5
The RX/TX FIFOs are created in xlnx_dp_init(), add xlnx_dp_finalize()
to destroy them.
Fixes: 58ac482 ("introduce xlnx-dp")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 19, 2024
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_size member to the AspeedGPIOClass structure. This
change ensures that the size of the GPIO register table is explicitly tracked
and initialized, reducing the risk of errors if new register tables are
introduced in the future.
Reproducer:
cat << EOF | qemu-system-aarch64 -display none \
-machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
readq 0x7e780272
EOF
ASAN log indicating the issue:
==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
READ of size 2 at 0x55a5da29e128 thread T0
#0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
#1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
#2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
#3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
#4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
#5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
#6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
#7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Andrew Jeffery <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 20, 2024
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_count member to the AspeedGPIOClass structure. This
change ensures that the size of the GPIO register table is explicitly tracked
and initialized, reducing the risk of errors if new register tables are
introduced in the future.
Reproducer:
cat << EOF | qemu-system-aarch64 -display none \
-machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
readq 0x7e780272
EOF
ASAN log indicating the issue:
==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
READ of size 2 at 0x55a5da29e128 thread T0
#0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
#1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
#2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
#3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
#4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
#5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
#6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
#7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 20, 2024
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_count member to the AspeedGPIOClass structure. This
change ensures that the size of the GPIO register table is explicitly tracked
and initialized, reducing the risk of errors if new register tables are
introduced in the future.
Reproducer:
cat << EOF | qemu-system-aarch64 -display none \
-machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
readq 0x7e780272
EOF
ASAN log indicating the issue:
==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
READ of size 2 at 0x55a5da29e128 thread T0
#0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
#1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
#2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
#3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
#4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
#5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
#6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
#7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 21, 2024
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_count member to the AspeedGPIOClass structure. This
change ensures that the size of the GPIO register table is explicitly tracked
and initialized, reducing the risk of errors if new register tables are
introduced in the future.
Reproducer:
cat << EOF | qemu-system-aarch64 -display none \
-machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
readq 0x7e780272
EOF
ASAN log indicating the issue:
==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
READ of size 2 at 0x55a5da29e128 thread T0
#0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
#1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
#2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
#3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
#4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
#5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
#6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
#7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Andrew Jeffery <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 25, 2024
For multi-bytes commands, our implementation uses the @data_start
and @data_offset fields to track byte access. We initialize the
command start/offset in buffer once. Malicious guest might abuse
by switching command while staying in the 'transfer' state, switching
command buffer size, and our implementation can access out of buffer
boundary. For example, CMD17 (READ_SINGLE_BLOCK) allows to read up to
512 bytes, and CMD13 (SEND_STATUS) up to 64 bytes. By switching from
CMD17 to CMD13 (see reproducer below), bytes [64-511] are out of the
'status' buffer.
Our implementation return R0 status code for unexpected commands.
Such in-transaction command switch is unexpected and returns R0.
This is a good place to reset the start/offset fields to avoid
malicious accesses.
Can be reproduced running:
$ export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
$ cat << EOF | qemu-system-i386 \
-display none -nographic \
-machine accel=qtest -m 512M \
-nodefaults \
-device sdhci-pci,sd-spec-version=3 \
-device sd-card,drive=mydrive \
-drive if=none,index=0,file=null-co://,format=raw,id=mydrive \
-qtest stdio -trace sd\* -trace -sdbus_read
outl 0xcf8 0x80001010
outl 0xcfc 0xe0000000
outl 0xcf8 0x80001004
outw 0xcfc 0x02
write 0xe000002c 0x1 0x05
write 0xe000000f 0x1 0x37
write 0xe000000a 0x1 0x01
write 0xe000000f 0x1 0x29
write 0xe000000f 0x1 0x02
write 0xe000000f 0x1 0x03
write 0xe000000c 0x1 0x32
write 0xe000000f 0x1 0x06
write 0xe0000005 0x1 0x01
write 0xe0000007 0x1 0x01
write 0xe0000003 0x1 0x00
write 0xe000000f 0x1 0x11
write 0xe000002a 0x1 0x01
write 0xe000002a 0x1 0x02
write 0xe000000f 0x1 0x0d
write 0xe000002a 0x1 0x01
write 0xe000002a 0x1 0x02
EOF
hw/sd/sd.c:1984:15: runtime error: index 256 out of bounds for type 'uint8_t [64]'
#0 sd_read_byte hw/sd/sd.c:1984:15
#1 sdbus_read_data hw/sd/core.c:157:23
#2 sdhci_read_block_from_card hw/sd/sdhci.c:423:9
#3 sdhci_blkgap_write hw/sd/sdhci.c:1074:13
#4 sdhci_write hw/sd/sdhci.c:1195:13
#5 memory_region_write_accessor softmmu/memory.c:492:5
#6 access_with_adjusted_size softmmu/memory.c:554:18
#7 memory_region_dispatch_write softmmu/memory.c
#8 flatview_write_continue softmmu/physmem.c:2778:23
#9 flatview_write softmmu/physmem.c:2818:14
#10 address_space_write softmmu/physmem.c:2910:18
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior hw/sd/sd.c:1984:15
Reported-by: Alexander Bulekov <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/487
Buglink: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36240
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 30, 2024
This patch addresses a potential out-of-bounds memory access issue in the
tcx_blit_writel function. It adds bounds checking to ensure that memory
accesses do not exceed the allocated VRAM size. If an out-of-bounds access
is detected, an error is logged using qemu_log_mask.
ASAN log:
==2960379==ERROR: AddressSanitizer: SEGV on unknown address 0x7f524752fd01 (pc 0x7f525c2c4881 bp 0x7ffdaf87bfd0 sp 0x7ffdaf87b788 T0)
==2960379==The signal is caused by a READ memory access.
#0 0x7f525c2c4881 in memcpy string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:222
#1 0x55aa782bd5b1 in __asan_memcpy llvm/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
#2 0x55aa7854dedd in tcx_blit_writel hw/display/tcx.c:590:13
Reproducer:
cat << EOF | qemu-system-sparc -display none \
-machine accel=qtest, -m 512M -machine LX -m 256 -qtest stdio
writel 0x562e98c4 0x3d92fd01
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 30, 2024
The musb_reset function was causing a memory leak by not properly freeing
the memory associated with USBPacket instances before reinitializing them.
This commit addresses the memory leak by adding calls to usb_packet_cleanup
for each USBPacket instance before reinitializing them with usb_packet_init.
Asan log:
=2970623==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 256 byte(s) in 16 object(s) allocated from:
#0 0x561e20629c3d in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7fee91885738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x561e21b4d0e1 in usb_packet_init hw/usb/core.c:531:5
#3 0x561e21c5016b in musb_reset hw/usb/hcd-musb.c:372:9
#4 0x561e21c502a9 in musb_init hw/usb/hcd-musb.c:385:5
#5 0x561e21c893ef in tusb6010_realize hw/usb/tusb6010.c:827:15
#6 0x561e23443355 in device_set_realized hw/core/qdev.c:510:13
#7 0x561e2346ac1b in property_set_bool qom/object.c:2354:5
#8 0x561e23463895 in object_property_set qom/object.c:1463:5
#9 0x561e23477909 in object_property_set_qobject qom/qom-qobject.c:28:10
#10 0x561e234645ed in object_property_set_bool qom/object.c:1533:15
#11 0x561e2343c830 in qdev_realize hw/core/qdev.c:291:12
#12 0x561e2343c874 in qdev_realize_and_unref hw/core/qdev.c:298:11
#13 0x561e20ad5091 in sysbus_realize_and_unref hw/core/sysbus.c:261:12
#14 0x561e22553283 in n8x0_usb_setup hw/arm/nseries.c:800:5
#15 0x561e2254e99b in n8x0_init hw/arm/nseries.c:1356:5
#16 0x561e22561170 in n810_init hw/arm/nseries.c:1418:5
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jun 30, 2024
The PL011 TRM says that "The 16-bit integer is written to the Integer Baud Rate
Register, UARTIBRD". Updated the handling of the UARTIBRD register to ensure
only 16-bit values are written to it.
ASAN log:
==2973125==ERROR: AddressSanitizer: FPE on unknown address 0x55f72629b348 (pc 0x55f72629b348 bp 0x7fffa24d0e00 sp 0x7fffa24d0d60 T0)
#0 0x55f72629b348 in pl011_get_baudrate hw/char/pl011.c:255:17
#1 0x55f726298d94 in pl011_trace_baudrate_change hw/char/pl011.c:260:33
#2 0x55f726296fc8 in pl011_write hw/char/pl011.c:378:9
Reproducer:
cat << EOF | qemu-system-aarch64 -display \
none -machine accel=qtest, -m 512M -machine realview-pb-a8 -qtest stdio
writeq 0x1000b024 0xf8000000
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 1, 2024
The musb_reset function was causing a memory leak by not properly freeing
the memory associated with USBPacket instances before reinitializing them.
This commit addresses the memory leak by adding calls to usb_packet_cleanup
for each USBPacket instance before reinitializing them with usb_packet_init.
Asan log:
=2970623==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 256 byte(s) in 16 object(s) allocated from:
#0 0x561e20629c3d in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7fee91885738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x561e21b4d0e1 in usb_packet_init hw/usb/core.c:531:5
#3 0x561e21c5016b in musb_reset hw/usb/hcd-musb.c:372:9
#4 0x561e21c502a9 in musb_init hw/usb/hcd-musb.c:385:5
#5 0x561e21c893ef in tusb6010_realize hw/usb/tusb6010.c:827:15
#6 0x561e23443355 in device_set_realized hw/core/qdev.c:510:13
#7 0x561e2346ac1b in property_set_bool qom/object.c:2354:5
#8 0x561e23463895 in object_property_set qom/object.c:1463:5
#9 0x561e23477909 in object_property_set_qobject qom/qom-qobject.c:28:10
#10 0x561e234645ed in object_property_set_bool qom/object.c:1533:15
#11 0x561e2343c830 in qdev_realize hw/core/qdev.c:291:12
#12 0x561e2343c874 in qdev_realize_and_unref hw/core/qdev.c:298:11
#13 0x561e20ad5091 in sysbus_realize_and_unref hw/core/sysbus.c:261:12
#14 0x561e22553283 in n8x0_usb_setup hw/arm/nseries.c:800:5
#15 0x561e2254e99b in n8x0_init hw/arm/nseries.c:1356:5
#16 0x561e22561170 in n810_init hw/arm/nseries.c:1418:5
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Xingtao Yao <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_count member to the AspeedGPIOClass structure. This
change ensures that the size of the GPIO register table is explicitly tracked
and initialized, reducing the risk of errors if new register tables are
introduced in the future.
Reproducer:
cat << EOF | qemu-system-aarch64 -display none \
-machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
readq 0x7e780272
EOF
ASAN log indicating the issue:
==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
READ of size 2 at 0x55a5da29e128 thread T0
#0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
#1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
#2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
#3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
#4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
#5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
#6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
#7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2355
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Andrew Jeffery <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
In pl011_get_baudrate(), when we calculate the baudrate we can
accidentally divide by zero. This happens because although (as the
specification requires) we treat UARTIBRD = 0 as invalid, we aren't
correctly limiting UARTIBRD and UARTFBRD values to the 16-bit and 6-bit
ranges the hardware allows, and so some non-zero values of UARTIBRD can
result in a zero divisor.
Enforce the correct register field widths on guest writes and on inbound
migration to avoid the division by zero.
ASAN log:
==2973125==ERROR: AddressSanitizer: FPE on unknown address 0x55f72629b348
(pc 0x55f72629b348 bp 0x7fffa24d0e00 sp 0x7fffa24d0d60 T0)
#0 0x55f72629b348 in pl011_get_baudrate hw/char/pl011.c:255:17
#1 0x55f726298d94 in pl011_trace_baudrate_change hw/char/pl011.c:260:33
#2 0x55f726296fc8 in pl011_write hw/char/pl011.c:378:9
Reproducer:
cat << EOF | qemu-system-aarch64 -display \
none -machine accel=qtest, -m 512M -machine realview-pb-a8 -qtest stdio
writeq 0x1000b024 0xf8000000
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
In pl011_get_baudrate(), when we calculate the baudrate we can
accidentally divide by zero. This happens because although (as the
specification requires) we treat UARTIBRD = 0 as invalid, we aren't
correctly limiting UARTIBRD and UARTFBRD values to the 16-bit and 6-bit
ranges the hardware allows, and so some non-zero values of UARTIBRD can
result in a zero divisor.
Enforce the correct register field widths on guest writes and on inbound
migration to avoid the division by zero.
ASAN log:
==2973125==ERROR: AddressSanitizer: FPE on unknown address 0x55f72629b348
(pc 0x55f72629b348 bp 0x7fffa24d0e00 sp 0x7fffa24d0d60 T0)
#0 0x55f72629b348 in pl011_get_baudrate hw/char/pl011.c:255:17
#1 0x55f726298d94 in pl011_trace_baudrate_change hw/char/pl011.c:260:33
#2 0x55f726296fc8 in pl011_write hw/char/pl011.c:378:9
Reproducer:
cat << EOF | qemu-system-aarch64 -display \
none -machine accel=qtest, -m 512M -machine realview-pb-a8 -qtest stdio
writeq 0x1000b024 0xf8000000
EOF
Suggested-by: Philippe Mathieu-Daudé <[email protected]>
Suggested-by: Peter Maydell <[email protected]>
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
In pl011_get_baudrate(), when we calculate the baudrate we can
accidentally divide by zero. This happens because although (as the
specification requires) we treat UARTIBRD = 0 as invalid, we aren't
correctly limiting UARTIBRD and UARTFBRD values to the 16-bit and 6-bit
ranges the hardware allows, and so some non-zero values of UARTIBRD can
result in a zero divisor.
Enforce the correct register field widths on guest writes and on inbound
migration to avoid the division by zero.
ASAN log:
==2973125==ERROR: AddressSanitizer: FPE on unknown address 0x55f72629b348
(pc 0x55f72629b348 bp 0x7fffa24d0e00 sp 0x7fffa24d0d60 T0)
#0 0x55f72629b348 in pl011_get_baudrate hw/char/pl011.c:255:17
#1 0x55f726298d94 in pl011_trace_baudrate_change hw/char/pl011.c:260:33
#2 0x55f726296fc8 in pl011_write hw/char/pl011.c:378:9
Reproducer:
cat << EOF | qemu-system-aarch64 -display \
none -machine accel=qtest, -m 512M -machine realview-pb-a8 -qtest stdio
writeq 0x1000b024 0xf8000000
EOF
Suggested-by: Philippe Mathieu-Daudé <[email protected]>
Suggested-by: Peter Maydell <[email protected]>
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
…te_asym_session
The assignment of the op_code in the virtio_crypto_create_asym_session
function was moved before its usage to ensure it is correctly set.
Previously, if the function failed during the key_len check, the op_code
did not have a proper value, causing virtio_crypto_free_create_session_req
to not free the memory correctly, leading to a memory leak.
By setting the op_code before performing any checks, we ensure that
virtio_crypto_free_create_session_req has the correct context to
perform cleanup operations properly, thus preventing memory leaks.
ASAN log:
==3055068==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x5586a75e6ddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7fb6b63b6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x5586a864bbde in virtio_crypto_handle_ctrl hw/virtio/virtio-crypto.c:407:19
#3 0x5586a94fc84c in virtio_queue_notify_vq hw/virtio/virtio.c:2277:9
#4 0x5586a94fc0a2 in virtio_queue_host_notifier_read hw/virtio/virtio.c:3641:9
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
…te_asym_session
The assignment of the op_code in the virtio_crypto_create_asym_session
function was moved before its usage to ensure it is correctly set.
Previously, if the function failed during the key_len check, the op_code
did not have a proper value, causing virtio_crypto_free_create_session_req
to not free the memory correctly, leading to a memory leak.
By setting the op_code before performing any checks, we ensure that
virtio_crypto_free_create_session_req has the correct context to
perform cleanup operations properly, thus preventing memory leaks.
ASAN log:
==3055068==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x5586a75e6ddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7fb6b63b6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x5586a864bbde in virtio_crypto_handle_ctrl hw/virtio/virtio-crypto.c:407:19
#3 0x5586a94fc84c in virtio_queue_notify_vq hw/virtio/virtio.c:2277:9
#4 0x5586a94fc0a2 in virtio_queue_host_notifier_read hw/virtio/virtio.c:3641:9
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
…te_asym_session
The assignment of the op_code in the virtio_crypto_create_asym_session
function was moved before its usage to ensure it is correctly set.
Previously, if the function failed during the key_len check, the op_code
did not have a proper value, causing virtio_crypto_free_create_session_req
to not free the memory correctly, leading to a memory leak.
By setting the op_code before performing any checks, we ensure that
virtio_crypto_free_create_session_req has the correct context to
perform cleanup operations properly, thus preventing memory leaks.
ASAN log:
==3055068==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x5586a75e6ddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7fb6b63b6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x5586a864bbde in virtio_crypto_handle_ctrl hw/virtio/virtio-crypto.c:407:19
#3 0x5586a94fc84c in virtio_queue_notify_vq hw/virtio/virtio.c:2277:9
#4 0x5586a94fc0a2 in virtio_queue_host_notifier_read hw/virtio/virtio.c:3641:9
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
…te_asym_session
Currently, if the function fails during the key_len check, the op_code
does not have a proper value, causing virtio_crypto_free_create_session_req
not to free the memory correctly, leading to a memory leak.
By setting the op_code before performing any checks, we ensure that
virtio_crypto_free_create_session_req has the correct context to
perform cleanup operations properly, thus preventing memory leaks.
ASAN log:
==3055068==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x5586a75e6ddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7fb6b63b6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x5586a864bbde in virtio_crypto_handle_ctrl hw/virtio/virtio-crypto.c:407:19
#3 0x5586a94fc84c in virtio_queue_notify_vq hw/virtio/virtio.c:2277:9
#4 0x5586a94fc0a2 in virtio_queue_host_notifier_read hw/virtio/virtio.c:3641:9
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
…nfig_write
In sm501_system_config_write(), we update the local memory size index
based on the incoming value. However, there was no check to ensure
that the index is within the valid range, which could result in
a buffer overflow.
This commit adds a check to ensure that the local memory size index
is within the valid range before updating it. If the index is not
valid, an error is logged and the index is not updated.
ASAN log:
==3067247==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55c6586e4d3c at pc 0x55c655d4e0ac bp 0x7ffc9d5c6a10 sp 0x7ffc9d5c6a08
READ of size 4 at 0x55c6586e4d3c thread T0
#0 0x55c655d4e0ab in sm501_2d_operation qemu/hw/display/sm501.c:729:21
#1 0x55c655d4b8a1 in sm501_2d_engine_write qemu/hw/display/sm501.c:1551:13
Reproducer:
cat << EOF | qemu-system-x86_64 \
-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \
-device sm501 -qtest stdio
outl 0xcf8 0x80000814
outl 0xcfc 0xe4000000
outl 0xcf8 0x80000804
outw 0xcfc 0x02
writel 0xe4000010 0xe000
writel 0xe4100010 0x10000
writel 0xe4100008 0x10001
writel 0xe410000c 0x80000000
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_count member to the AspeedGPIOClass structure. This
change ensures that the size of the GPIO register table is explicitly tracked
and initialized, reducing the risk of errors if new register tables are
introduced in the future.
Reproducer:
cat << EOF | qemu-system-aarch64 -display none \
-machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
readq 0x7e780272
EOF
ASAN log indicating the issue:
==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
READ of size 2 at 0x55a5da29e128 thread T0
#0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
#1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
#2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
#3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
#4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
#5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
#6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
#7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2355
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Andrew Jeffery <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 2, 2024
The allocated memory to hold LBA ranges leaks in the nvme_dsm function. This
happens because the allocated memory for iocb->range is not freed in all
error handling paths.
Fix this by adding a free to ensure that the allocated memory is properly freed.
ASAN log:
==3075137==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 480 byte(s) in 6 object(s) allocated from:
#0 0x55f1f8a0eddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7f531e0f6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x55f1faf1f091 in blk_aio_get block/block-backend.c:2583:12
#3 0x55f1f945c74b in nvme_dsm hw/nvme/ctrl.c:2609:30
#4 0x55f1f945831b in nvme_io_cmd hw/nvme/ctrl.c:4470:16
#5 0x55f1f94561b7 in nvme_process_sq hw/nvme/ctrl.c:7039:29
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 3, 2024
The allocated memory to hold LBA ranges leaks in the nvme_dsm function. This
happens because the allocated memory for iocb->range is not freed in all
error handling paths.
Fix this by adding a free to ensure that the allocated memory is properly freed.
ASAN log:
==3075137==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 480 byte(s) in 6 object(s) allocated from:
#0 0x55f1f8a0eddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7f531e0f6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x55f1faf1f091 in blk_aio_get block/block-backend.c:2583:12
#3 0x55f1f945c74b in nvme_dsm hw/nvme/ctrl.c:2609:30
#4 0x55f1f945831b in nvme_io_cmd hw/nvme/ctrl.c:4470:16
#5 0x55f1f94561b7 in nvme_process_sq hw/nvme/ctrl.c:7039:29
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Xingtao Yao <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 3, 2024
…nfig_write
Ensure that the local_mem_size_index is within valid bounds and does not
exceed the allocated memory size before updating it in sm501_system_config_write
to prevent out-of-bounds read.
ASAN log:
==3067247==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55c6586e4d3c at pc 0x55c655d4e0ac bp 0x7ffc9d5c6a10 sp 0x7ffc9d5c6a08
READ of size 4 at 0x55c6586e4d3c thread T0
#0 0x55c655d4e0ab in sm501_2d_operation qemu/hw/display/sm501.c:729:21
#1 0x55c655d4b8a1 in sm501_2d_engine_write qemu/hw/display/sm501.c:1551:13
Reproducer:
cat << EOF | qemu-system-x86_64 \
-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \
-device sm501 -qtest stdio
outl 0xcf8 0x80000814
outl 0xcfc 0xe4000000
outl 0xcf8 0x80000804
outw 0xcfc 0x02
writel 0xe4000010 0xe000
writel 0xe4100010 0x10000
writel 0xe4100008 0x10001
writel 0xe410000c 0x80000000
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 3, 2024
…eration
The sifive_plic_read function in hw/intc/sifive_plic.c had a potential
heap-buffer-overflow issue when reading from the pending_base region.
This occurred because the code did not check if the calculated word index
was within valid bounds before accessing the pending array.
This fix prevents out-of-bounds memory access, ensuring safer and more
robust handling of PLIC reads.
ASAN log:
==78800==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000038a14 at pc 0x5baf49d0d6cb bp 0x7ffc2ea4e180 sp 0x7ffc2ea4e178
READ of size 4 at 0x602000038a14 thread T0
#0 0x5baf49d0d6ca in sifive_plic_read hw/intc/sifive_plic.c:151:16
#1 0x5baf49f7f3bb in memory_region_read_accessor system/memory.c:445:11
Reproducer:
cat << EOF | qemu-system-riscv64 -display \
none -machine accel=qtest, -m 512M -machine shakti_c -m 2G -qtest stdio
readl 0xc001004
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 10, 2024
The allocated memory to hold LBA ranges leaks in the nvme_dsm function. This
happens because the allocated memory for iocb->range is not freed in all
error handling paths.
Fix this by adding a free to ensure that the allocated memory is properly freed.
ASAN log:
==3075137==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 480 byte(s) in 6 object(s) allocated from:
#0 0x55f1f8a0eddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7f531e0f6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x55f1faf1f091 in blk_aio_get block/block-backend.c:2583:12
#3 0x55f1f945c74b in nvme_dsm hw/nvme/ctrl.c:2609:30
#4 0x55f1f945831b in nvme_io_cmd hw/nvme/ctrl.c:4470:16
#5 0x55f1f94561b7 in nvme_process_sq hw/nvme/ctrl.c:7039:29
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Klaus Jensen <[email protected]>
Reviewed-by: Xingtao Yao <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 11, 2024
In pl011_get_baudrate(), when we calculate the baudrate we can
accidentally divide by zero. This happens because although (as the
specification requires) we treat UARTIBRD = 0 as invalid, we aren't
correctly limiting UARTIBRD and UARTFBRD values to the 16-bit and 6-bit
ranges the hardware allows, and so some non-zero values of UARTIBRD can
result in a zero divisor.
Enforce the correct register field widths on guest writes and on inbound
migration to avoid the division by zero.
ASAN log:
==2973125==ERROR: AddressSanitizer: FPE on unknown address 0x55f72629b348
(pc 0x55f72629b348 bp 0x7fffa24d0e00 sp 0x7fffa24d0d60 T0)
#0 0x55f72629b348 in pl011_get_baudrate hw/char/pl011.c:255:17
#1 0x55f726298d94 in pl011_trace_baudrate_change hw/char/pl011.c:260:33
#2 0x55f726296fc8 in pl011_write hw/char/pl011.c:378:9
Reproducer:
cat << EOF | qemu-system-aarch64 -display \
none -machine accel=qtest, -m 512M -machine realview-pb-a8 -qtest stdio
writeq 0x1000b024 0xf8000000
EOF
Suggested-by: Peter Maydell <[email protected]>
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 11, 2024
Commit 73064ed ("hw/nvme: flexible data placement emulation") intorudced NVMe FDP feature to nvme-subsys and nvme-ctrl with a single endurance group #1 supported. This means that controller should return proper identify data to host with Identify Endurance Group List (CNS 19h). But, yes, only just for the endurance group #1. This patch allows host applications to ask for which endurance group is available and utilize FDP through that endurance group. Reviewed-by: Klaus Jensen <[email protected]> Signed-off-by: Minwoo Im <[email protected]> Signed-off-by: Klaus Jensen <[email protected]> Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 11, 2024
In pl011_get_baudrate(), when we calculate the baudrate we can
accidentally divide by zero. This happens because although (as the
specification requires) we treat UARTIBRD = 0 as invalid, we aren't
correctly limiting UARTIBRD and UARTFBRD values to the 16-bit and 6-bit
ranges the hardware allows, and so some non-zero values of UARTIBRD can
result in a zero divisor.
Enforce the correct register field widths on guest writes and on inbound
migration to avoid the division by zero.
ASAN log:
==2973125==ERROR: AddressSanitizer: FPE on unknown address 0x55f72629b348
(pc 0x55f72629b348 bp 0x7fffa24d0e00 sp 0x7fffa24d0d60 T0)
#0 0x55f72629b348 in pl011_get_baudrate hw/char/pl011.c:255:17
#1 0x55f726298d94 in pl011_trace_baudrate_change hw/char/pl011.c:260:33
#2 0x55f726296fc8 in pl011_write hw/char/pl011.c:378:9
Reproducer:
cat << EOF | qemu-system-aarch64 -display \
none -machine accel=qtest, -m 512M -machine realview-pb-a8 -qtest stdio
writeq 0x1000b024 0xf8000000
EOF
Suggested-by: Peter Maydell <[email protected]>
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 12, 2024
Commit 73064ed ("hw/nvme: flexible data placement emulation") intorudced NVMe FDP feature to nvme-subsys and nvme-ctrl with a single endurance group #1 supported. This means that controller should return proper identify data to host with Identify Endurance Group List (CNS 19h). But, yes, only just for the endurance group #1. This patch allows host applications to ask for which endurance group is available and utilize FDP through that endurance group. Reviewed-by: Klaus Jensen <[email protected]> Signed-off-by: Minwoo Im <[email protected]> Signed-off-by: Klaus Jensen <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 17, 2024
This patch addresses potential issues in the sm501 memory size
configuration. Specifically, it adds validation checks to ensure that
the local_mem_size_index value written to the SM501_DRAM_CONTROL
register is within valid bounds. It ensures that the selected memory
size does not exceed the available VRAM size.
Additionally, the read operation for the SM501_DRAM_CONTROL register
is modified to return the raw dram_control value without combining it
with the local_mem_size_index.
ASAN log:
==3067247==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55c6586e4d3c at pc 0x55c655d4e0ac bp 0x7ffc9d5c6a10 sp 0x7ffc9d5c6a08
READ of size 4 at 0x55c6586e4d3c thread T0
#0 0x55c655d4e0ab in sm501_2d_operation qemu/hw/display/sm501.c:729:21
#1 0x55c655d4b8a1 in sm501_2d_engine_write qemu/hw/display/sm501.c:1551:13
Reproducer:
cat << EOF | qemu-system-x86_64 \
-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \
-device sm501 -qtest stdio
outl 0xcf8 0x80000814
outl 0xcfc 0xe4000000
outl 0xcf8 0x80000804
outw 0xcfc 0x02
writel 0xe4000010 0xe000
writel 0xe4100010 0x10000
writel 0xe4100008 0x10001
writel 0xe410000c 0x80000000
EOF
Signed-off-by: Zheyu Ma <[email protected]>
Message-Id: <[email protected]>
patchew-importer
pushed a commit
that referenced
this issue
Jul 23, 2024
The allocated memory to hold LBA ranges leaks in the nvme_dsm function. This
happens because the allocated memory for iocb->range is not freed in all
error handling paths.
Fix this by adding a free to ensure that the allocated memory is properly freed.
ASAN log:
==3075137==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 480 byte(s) in 6 object(s) allocated from:
#0 0x55f1f8a0eddd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
#1 0x7f531e0f6738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738)
#2 0x55f1faf1f091 in blk_aio_get block/block-backend.c:2583:12
#3 0x55f1f945c74b in nvme_dsm hw/nvme/ctrl.c:2609:30
#4 0x55f1f945831b in nvme_io_cmd hw/nvme/ctrl.c:4470:16
#5 0x55f1f94561b7 in nvme_process_sq hw/nvme/ctrl.c:7039:29
Cc: [email protected]
Fixes: d7d1474 ("hw/nvme: reimplement dsm to allow cancellation")
Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Klaus Jensen <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have edited the brew formula for qemu to point to this repository, but build fails for meson.build at curses. I have included the configure log. I am using the patches published by Alexander Graff to enable hypervisor framework.
The text was updated successfully, but these errors were encountered: