diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1907 | 72 | ||||
| -rw-r--r-- | results/classifier/108/other/1907042 | 67 | ||||
| -rw-r--r-- | results/classifier/108/other/1907061 | 63 | ||||
| -rw-r--r-- | results/classifier/108/other/1907137 | 163 | ||||
| -rw-r--r-- | results/classifier/108/other/1907210 | 68 | ||||
| -rw-r--r-- | results/classifier/108/other/1907497 | 97 | ||||
| -rw-r--r-- | results/classifier/108/other/1907776 | 73 | ||||
| -rw-r--r-- | results/classifier/108/other/1907817 | 67 | ||||
| -rw-r--r-- | results/classifier/108/other/1907909 | 79 | ||||
| -rw-r--r-- | results/classifier/108/other/1907938 | 99 | ||||
| -rw-r--r-- | results/classifier/108/other/1907952 | 197 | ||||
| -rw-r--r-- | results/classifier/108/other/1907953 | 21 |
12 files changed, 1066 insertions, 0 deletions
diff --git a/results/classifier/108/other/1907 b/results/classifier/108/other/1907 new file mode 100644 index 000000000..5d0db5026 --- /dev/null +++ b/results/classifier/108/other/1907 @@ -0,0 +1,72 @@ +permissions: 0.830 +other: 0.808 +KVM: 0.770 +semantic: 0.747 +graphic: 0.730 +vnc: 0.724 +PID: 0.713 +debug: 0.678 +performance: 0.667 +boot: 0.657 +device: 0.651 +network: 0.638 +files: 0.624 +socket: 0.622 + +QEMU LoongArch regression after merging LASX changes +Description of problem: +After enabling LASX in qemu (@gaosong), booting Gentoo Linux with latest glibc master (w/ LSX & LASX optimized libc routines) will fail in systemd: + +``` +[ 10.350207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000085 +[ 10.350557] CPU: 5 PID: 1 Comm: systemd Not tainted 6.5.2-gentoo #2 +[ 10.350655] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 +[ 10.350961] Stack : 0072617764726148 0000000000000000 9000000000223440 90000001000e4000 +[ 10.351181] 90000001000e7990 90000001000e7998 0000000000000000 90000001000e7ad8 +[ 10.351294] 90000001000e7ad0 90000001000e7ad0 90000001000e7900 0000000000000001 +[ 10.351406] 0000000000000001 90000001000e7998 ec94a2e1446052e6 9000000100438140 +[ 10.351519] 0000000000000001 0000000000000003 0000000000000000 0000000000000030 +[ 10.351630] 0000000000000000 00000000000559bf 00000000056e0000 0000000000000004 +[ 10.351745] 0000000000000000 0000000000000000 900000000162b438 900000000177e000 +[ 10.351856] 00000000400004d8 0000000000000001 0000000000000018 90000001000e7c84 +[ 10.351968] 0000000000020000 0000000000000000 9000000000223458 00007ffff0341af0 +[ 10.352081] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c +[ 10.352196] ... +[ 10.352277] Call Trace: +[ 10.352482] [<9000000000223458>] show_stack+0x5c/0x180 +[ 10.353518] [<9000000001178d4c>] dump_stack_lvl+0x60/0x88 +[ 10.353592] [<900000000115cd7c>] panic+0x13c/0x308 +[ 10.353670] [<900000000024244c>] do_exit+0x860/0x868 +[ 10.353735] [<900000000024261c>] do_group_exit+0x34/0x94 +[ 10.353803] [<9000000000250514>] get_signal+0x75c/0x804 +[ 10.353869] [<90000000002254c4>] arch_do_signal_or_restart+0x74/0xae0 +[ 10.353944] [<90000000002c738c>] exit_to_user_mode_loop.isra.0+0x90/0x10c +[ 10.354041] [<9000000001179ff0>] irqentry_exit_to_user_mode+0x1c/0x28 +[ 10.354119] [<90000000011792f8>] do_bp+0xcc/0x2ac +[ 10.354222] [<90000001005a1924>] 0x90000001005a1924 +[ 10.354522] [<00007ffff0341af0>] 0x7ffff0341af0 +``` + +Full log: + +[stderr](/uploads/61b9870ae2441c9a25f44791c67889b8/stderr) + +Instruction trace `-d in_asm,out_asm,op` (very large): + +[log.tar.zstd](https://cloud.tsinghua.edu.cn/f/a83eac6d44694ede8cb1/?dl=1) + +I also tried to boot LoongArchLinux whose glibc does not have LSX/LASX optimized C routines, and it can boot without problems. If I chroot from LoongArchLinux into Gentoo Linux, running `emerge` command will SIGSEGV. + +If I disable LASX in CPUCFG2, the problem is gone: + +```cpp +// data = FIELD_DP32(data, CPUCFG2, LASX, 1), +``` + +I guess the bug is related to LASX assemblies in [glibc](https://github.com/bminor/glibc/tree/master/sysdeps/loongarch/lp64/multiarch). +Steps to reproduce: +1. Launch qemu +2. Wait for systemd to be killed +3. Collect logs +Additional information: + diff --git a/results/classifier/108/other/1907042 b/results/classifier/108/other/1907042 new file mode 100644 index 000000000..19b427554 --- /dev/null +++ b/results/classifier/108/other/1907042 @@ -0,0 +1,67 @@ +permissions: 0.838 +performance: 0.749 +device: 0.708 +other: 0.661 +graphic: 0.652 +files: 0.648 +KVM: 0.631 +socket: 0.588 +semantic: 0.578 +vnc: 0.575 +boot: 0.572 +debug: 0.569 +PID: 0.566 +network: 0.540 + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed + +Hello, + +An assertion failure was found in hw/usb/core.c:727 in latest version 5.2.0. + +Reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 -trace usb\* + +Backtrace is as follows: +#0 0x00007f13fff14438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f13fff1603a in __GI_abort () at abort.c:89 +#2 0x00007f13fff0cbe7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=file@entry=0x55f97745f6c0 "../hw/usb/core.c", line=line@entry=727, function=function@entry=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:92 +#3 0x00007f13fff0cc92 in __GI___assert_fail (assertion=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x55f97745f6c0 "../hw/usb/core.c", line=727, function=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:101 +#4 0x000055f975bfc9b2 in usb_ep_get (dev=0x62300000c500, pid=45, ep=1) at ../hw/usb/core.c:727 +#5 0x000055f975f945db in ohci_service_td (ohci=0x6270000191f0, ed=0x7ffcd9308410) at ../hw/usb/hcd-ohci.c:1044 +#6 0x000055f975f95d5e in ohci_service_ed_list (ohci=0x6270000191f0, head=857580576, completion=0) at ../hw/usb/hcd-ohci.c:1200 +#7 0x000055f975f9656d in ohci_process_lists (ohci=0x6270000191f0, completion=0) at ../hw/usb/hcd-ohci.c:1238 +#8 0x000055f975f9725c in ohci_frame_boundary (opaque=0x6270000191f0) at ../hw/usb/hcd-ohci.c:1281 +#9 0x000055f977212494 in timerlist_run_timers (timer_list=0x60b00005b060) at ../util/qemu-timer.c:574 +#10 0x000055f9772126db in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#11 0x000055f977212fde in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#12 0x000055f9772d5717 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531 +#13 0x000055f97695100c in qemu_main_loop () at ../softmmu/vl.c:1677 +#14 0x000055f9758f7601 in main (argc=16, argv=0x7ffcd9308888, envp=0x7ffcd9308910) at ../softmmu/main.c:50 +#15 0x00007f13ffeff840 in __libc_start_main (main=0x55f9758f75b0 <main>, argc=16, argv=0x7ffcd9308888, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd9308878) at ../csu/libc-start.c:291 +#16 0x000055f9758f74a9 in _start () + + +The poc is attached. + +Thanks. + + + +I trigger the usb_ep_get assertion as well, but I think is't not a bug.(I use the ehci) +Maybe the logic is the function return ep_ctl whith USB_TOKEN_SETUP and ep==0.Otherwise, will goto the next. + +This looks like a dupe of https://bugs.launchpad.net/qemu/+bug/1525123/ , though through OHCI rather than XHCI + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/303 + + diff --git a/results/classifier/108/other/1907061 b/results/classifier/108/other/1907061 new file mode 100644 index 000000000..d89e575ee --- /dev/null +++ b/results/classifier/108/other/1907061 @@ -0,0 +1,63 @@ +performance: 0.873 +graphic: 0.856 +other: 0.825 +device: 0.744 +PID: 0.663 +network: 0.650 +semantic: 0.633 +files: 0.622 +socket: 0.543 +debug: 0.542 +permissions: 0.523 +vnc: 0.451 +boot: 0.375 +KVM: 0.359 + +qemu-system-x86_64 minimizing window causes keyboard input lag globally + +After qemu window is minimized, it causes keyboard lag on the host for all applications, pressed keys will be delayed and very laggy, typing to notepad or any other text extremely slowly appear on the screen, queue is slowly processed. +If qemu window is open back to normal size, keyboard is back to normal, everything is back to normal and stable, this behavior i have been testing since several months of qemu releases, i am reporting a bit late here, not breaking but it seems important and everytime i accidently minimize qemu, i remember it later and take qemu window to normal size back always, i try never minimize it anymore. +This problem does not occur if using -display none +Guest OS doesn't matter for this behavior, result is always same +I am using: +qemu 5.1.0.0 +qemu-system-x86_64w.exe +Windows 10 build 2004 +4K screen dpi scaling set to 150% + +If requested, i can record a video to see the problem clearly, but i think all information i give already clear now. + +Thanks for making quality software, hope all bugs fixed + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1907137 b/results/classifier/108/other/1907137 new file mode 100644 index 000000000..84d5bc20e --- /dev/null +++ b/results/classifier/108/other/1907137 @@ -0,0 +1,163 @@ +graphic: 0.884 +debug: 0.862 +permissions: 0.843 +other: 0.804 +semantic: 0.802 +performance: 0.798 +PID: 0.790 +socket: 0.786 +device: 0.781 +vnc: 0.751 +KVM: 0.712 +network: 0.709 +boot: 0.669 +files: 0.669 + +LDTR not properly emulated when MTE tag checks enabled at EL0 + +I am trying to boot Android (just the non-GUI parts for now) under QEMU with MTE enabled. This can be done by following the instructions here to build the fvp-eng target with MTE support: + +https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/ + +and launching QEMU with the following command: + +qemu-system-aarch64 -kernel $ANDROID_PRODUCT_OUT/kernel -initrd $ANDROID_PRODUCT_OUT/combined-ramdisk.img -machine virt,mte=on -cpu max -drive driver=raw,file=$ANDROID_PRODUCT_OUT/system-qemu.img,if=none,id=system -device virtio-blk-device,drive=system -append "console=ttyAMA0 earlyprintk=ttyAMA0 androidboot.hardware=fvpbase androidboot.boot_devices=a003e00.virtio_mmio loglevel=9 printk.devkmsg=on buildvariant=eng" -m 512 -nographic -no-reboot + +If I do this then QEMU crashes like so: + +** +ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached +Bail out! ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached + +The error is caused by an MTE tag check fault from an LDTR instruction in __arch_copy_from_user. At this point TCF=0 and TCF0=2. + +I have this patch that gets me past the error but it is unclear whether this is the correct fix since there may be other confusion between TCF and TCF0 elsewhere. + +diff --git a/target/arm/mte_helper.c b/target/arm/mte_helper.c +index 153bd1e9df..aa5db4eac4 100644 +--- a/target/arm/mte_helper.c ++++ b/target/arm/mte_helper.c +@@ -552,10 +552,8 @@ static void mte_check_fail(CPUARMState *env, uint32_t desc, + case 0: + /* + * Tag check fail does not affect the PE. +- * We eliminate this case by not setting MTE_ACTIVE +- * in tb_flags, so that we never make this runtime call. + */ +- g_assert_not_reached(); ++ break; + + case 2: + /* Tag check fail causes asynchronous flag set. */ + +The workaround patch above is insufficient if I change userspace to set TCF0=1. With that I get a kernel panic: + +[ 13.336255][ C0] Bad mode in Synchronous Abort handler detected on CPU0, code 0x92000011 -- DABT (lower EL) +[ 13.337437][ C0] CPU: 0 PID: 1 Comm: init Not tainted 5.10.0-rc7-mainline-00300-gf4328758abb6 #1 +[ 13.338086][ C0] Hardware name: linux,dummy-virt (DT) +[ 13.338948][ C0] pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--) +[ 13.339951][ C0] pc : __arch_copy_from_user+0x1e4/0x340 +[ 13.340483][ C0] lr : _copy_from_user+0xbc/0x564 +[ 13.340930][ C0] sp : ffffffc01000bda0 +[ 13.341385][ C0] x29: ffffffc01000bda0 +[ 13.342295][ C0] x28: ffffff804011c100 +[ 13.342951][ C0] +[ 13.343321][ C0] x27: 0000000000000000 +[ 13.343759][ C0] x26: 0000000000000000 +[ 13.344178][ C0] +[ 13.344513][ C0] x25: 0000000000000000 +[ 13.344954][ C0] x24: 0000000000000000 +[ 13.345382][ C0] +[ 13.345713][ C0] x23: 0300007e18aca850 +[ 13.346153][ C0] x22: 0300007e18aca860 +[ 13.346809][ C0] +[ 13.347144][ C0] x21: ffffff8043d1ef80 +[ 13.347596][ C0] x20: 0300007e18aca850 +[ 13.348023][ C0] +[ 13.348354][ C0] x19: ffffff8043295000 +[ 13.348806][ C0] x18: ffffff8040103c38 +[ 13.349232][ C0] +[ 13.349557][ C0] x17: 0000000004000000 +[ 13.349998][ C0] x16: 0000007fffffffff +[ 13.350634][ C0] +[ 13.350965][ C0] x15: 0000007f9fed34f8 +[ 13.351409][ C0] x14: 006d65747379730c +[ 13.351844][ C0] +[ 13.352167][ C0] x13: 00000000000001ed +[ 13.352610][ C0] x12: 0000000000000000 +[ 13.353034][ C0] +[ 13.353358][ C0] x11: 0000000000000000 +[ 13.353802][ C0] x10: 0000000000000000 +[ 13.354232][ C0] +[ 13.354785][ C0] x9 : 006d65747379730c +[ 13.355236][ C0] x8 : 0000000000000000 +[ 13.355673][ C0] +[ 13.355998][ C0] x7 : 0000000000000000 +[ 13.356448][ C0] x6 : ffffff8043295040 +[ 13.356874][ C0] +[ 13.357200][ C0] x5 : ffffff8043296000 +[ 13.357646][ C0] x4 : 0000000000000000 +[ 13.358077][ C0] +[ 13.358423][ C0] x3 : 0000000000000001 +[ 13.359055][ C0] x2 : 0000000000000f80 +[ 13.359497][ C0] +[ 13.359829][ C0] x1 : 0300007e18aca8c0 +[ 13.360278][ C0] x0 : ffffff8043295000 +[ 13.360705][ C0] +[ 13.362315][ C0] Kernel panic - not syncing: bad mode +[ 13.362377][ C0] CPU: 0 PID: 1 Comm: init Not tainted 5.10.0-rc7-mainline-00300-gf4328758abb6 #1 +[ 13.362410][ C0] Hardware name: linux,dummy-virt (DT) +[ 13.362442][ C0] Call trace: +[ 13.362474][ C0] dump_backtrace+0x0/0x1e0 +[ 13.362507][ C0] show_stack+0x1c/0x2c +[ 13.362539][ C0] dump_stack+0xd0/0x154 +[ 13.362570][ C0] panic+0x158/0x370 +[ 13.362602][ C0] bad_el0_sync+0x0/0x5c +[ 13.362634][ C0] el1_inv+0x3c/0x5c +[ 13.362666][ C0] el1_sync_handler+0x64/0x8c +[ 13.362698][ C0] el1_sync+0x84/0x140 +[ 13.362730][ C0] __arch_copy_from_user+0x1e4/0x340 +[ 13.362762][ C0] copy_mount_options+0x40/0x1d0 +[ 13.362794][ C0] __arm64_sys_mount+0x84/0x13c +[ 13.362826][ C0] el0_svc_common+0xc0/0x1b4 +[ 13.362858][ C0] do_el0_svc+0x20/0x30 +[ 13.362890][ C0] el0_svc+0x14/0x24 +[ 13.362922][ C0] el0_sync_handler+0x88/0xec +[ 13.362953][ C0] el0_sync+0x17c/0x180 +[ 13.363547][ C0] Kernel Offset: 0x2abd800000 from 0xffffffc010000000 +[ 13.363580][ C0] PHYS_OFFSET: 0x40000000 +[ 13.363613][ C0] CPU features: 0x27e0152,6180a230 +[ 13.363644][ C0] Memory Limit: none + +It looks like the tag check fault coming from the LDTR is reported using the wrong EL. + +From the hash id in your patch, it would appear that you are using a fork of qemu. + +This should be fixed by 50244cc76abc present in the qemu 5.2 release. + +This isn't a fork of qemu, it was an upstream checkout based on commit 944fdc5e27a5b5adbb765891e8e70e88ba9a00ec (well, okay, I did have the ARM HVF series applied to this checkout, but I wouldn't expect that to affect TCG). I verified that 50244cc76abc is present in my checkout. + +Let me see if I can reproduce with the current upstream master. + +Ok, I'll have a deeper look as well. + +rebuild_hflags_a64 is not consistent with mte_check_fail, +which leads to the assert reported. + +The instructions for building the android kernel are opaque, +assuming tools not in evidence. + +Thanks, I will try that patch. + +Apologies, the instructions assume some familiarity with building Android. You will find instructions for downloading the "repo" tool and the Android source tree here: + +https://source.android.com/setup/build/downloading + +This isn't the first time I've received this kind of feedback. I will add a link to that page to the document. + +Thanks for the patch. I've verified that it fixes the assertion failure with both TCF0=1 and TCF0=2. + +You can disregard the kernel panic from comment #1 since it turns out that it was from an older build of QEMU that did not have 50244cc76abc. + +https://gitlab.com/qemu-project/qemu/-/commit/cc97b0019bb590b9b3c + diff --git a/results/classifier/108/other/1907210 b/results/classifier/108/other/1907210 new file mode 100644 index 000000000..35fbf069a --- /dev/null +++ b/results/classifier/108/other/1907210 @@ -0,0 +1,68 @@ +graphic: 0.822 +semantic: 0.808 +other: 0.782 +performance: 0.744 +debug: 0.711 +permissions: 0.706 +device: 0.676 +network: 0.668 +vnc: 0.665 +socket: 0.664 +PID: 0.650 +files: 0.626 +KVM: 0.520 +boot: 0.404 + +QEMU gdbstub command "?" issue + +I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. +Here is documentation from official gdb: +‘?’ Indicate the reason the target halted. The reply is the same as for step and +continue. This packet has a special interpretation when the target is in non-stop +mode; see Section E.10 [Remote Non-Stop], page 733. +Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. + +With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). +Function that handles "?" command has this comment in it: + /* + * Remove all the breakpoints when this query is issued, + * because gdb is doing an initial connect and the state + * should be cleaned up. + */ +From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. +In my opinion initial connect should be detected in some other way, and not with "?" command. + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1907497 b/results/classifier/108/other/1907497 new file mode 100644 index 000000000..8c6b5731e --- /dev/null +++ b/results/classifier/108/other/1907497 @@ -0,0 +1,97 @@ +other: 0.893 +KVM: 0.860 +performance: 0.835 +device: 0.833 +permissions: 0.818 +graphic: 0.790 +vnc: 0.757 +boot: 0.747 +debug: 0.743 +socket: 0.739 +semantic: 0.731 +files: 0.730 +PID: 0.722 +network: 0.704 + +[OSS-Fuzz] Issue 28435 qemu:qemu-fuzz-i386-target-generic-fuzz-intel-hda: Stack-overflow in ldl_le_dma + + affects qemu + +=== Reproducer (build with --enable-sanitizers) === + +cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +-device intel-hda,id=hda0 -device hda-output,bus=hda0.0 \ +-device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 \ +-qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0xffff +write 0x0 0x1 0x12 +write 0x2 0x1 0x2f +outl 0xcf8 0x80000811 +outl 0xcfc 0x5a6a4406 +write 0x6a44005a 0x1 0x11 +write 0x6a44005c 0x1 0x3f +write 0x6a442050 0x4 0x0000446a +write 0x6a44204a 0x1 0xf3 +write 0x6a44204c 0x1 0xff +writeq 0x6a44005a 0x17b3f0011 +write 0x6a442050 0x4 0x0000446a +write 0x6a44204a 0x1 0xf3 +write 0x6a44204c 0x1 0xff +EOF + +=== Stack Trace === +==411958==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcaeb8bc88 (pc 0x55c7c9dc1159 bp 0x7ffcaeb8c4d0 sp 0x7ffcaeb8bc90 T0) + #0 0x55c7c9dc1159 in __asan_memcpy (u-system-i386+0x2a13159) + #1 0x55c7cb2a457e in flatview_do_translate softmmu/physmem.c:513:12 + #2 0x55c7cb2bdab0 in flatview_translate softmmu/physmem.c:563:15 + #3 0x55c7cb2bdab0 in flatview_read softmmu/physmem.c:2861:10 + #4 0x55c7cb2bdab0 in address_space_read_full softmmu/physmem.c:2875:18 + #5 0x55c7caaec937 in dma_memory_rw_relaxed include/sysemu/dma.h:87:18 + #6 0x55c7caaec937 in dma_memory_rw include/sysemu/dma.h:110:12 + #7 0x55c7caaec937 in dma_memory_read include/sysemu/dma.h:116:12 + #8 0x55c7caaec937 in ldl_le_dma include/sysemu/dma.h:179:1 + #9 0x55c7caaec937 in ldl_le_pci_dma include/hw/pci/pci.h:816:1 + #10 0x55c7caaec937 in intel_hda_corb_run hw/audio/intel-hda.c:338:16 + #11 0x55c7cb2e7198 in memory_region_write_accessor softmmu/memory.c:491:5 + #12 0x55c7cb2e6bd3 in access_with_adjusted_size softmmu/memory.c:552:18 + #13 0x55c7cb2e646c in memory_region_dispatch_write softmmu/memory.c + #14 0x55c7cb2c8445 in flatview_write_continue softmmu/physmem.c:2759:23 + #15 0x55c7cb2bdfb8 in flatview_write softmmu/physmem.c:2799:14 + #16 0x55c7cb2bdfb8 in address_space_write softmmu/physmem.c:2891:18 + #17 0x55c7caae2c54 in dma_memory_rw_relaxed include/sysemu/dma.h:87:18 + #18 0x55c7caae2c54 in dma_memory_rw include/sysemu/dma.h:110:12 + #19 0x55c7caae2c54 in dma_memory_write include/sysemu/dma.h:122:12 + #20 0x55c7caae2c54 in stl_le_dma include/sysemu/dma.h:179:1 + #21 0x55c7caae2c54 in stl_le_pci_dma include/hw/pci/pci.h:816:1 + #22 0x55c7caae2c54 in intel_hda_response hw/audio/intel-hda.c:370:5 + #23 0x55c7caaeca00 in intel_hda_corb_run hw/audio/intel-hda.c:342:9 + #24 0x55c7cb2e7198 in memory_region_write_accessor softmmu/memory.c:491:5 +... + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28435 + + + +I think this [0] commit actually fixes this bug, can someone please confirm it? + +[0] https://github.com/qemu/qemu/commit/1bf8b88f144bee747e386c88d45d772e066bbb36 + +No, I can still reproduce this issue with current version from the git repo (commit 8f521741e1280f0957ac1) ... when I compile QEMU with Clang and --enable-sanitizers, the reproducer still crashes with "ERROR: AddressSanitizer: stack-overflow" + +Just FYI, this issue was assigned CVE-2021-3611 by Red Hat. + +@Thomas, could you try by compiling qemu with a commit close to the timeframe mentioned here [0]? + +[0] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28435#c2 + +@Gianluca: The problem still reproduces with the current master branch (commit 13d5f87cc3b94bfccc5), so the problem is definitely not fixed yet. So no, I certainly won't waste my time trying it on older versions. + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/542 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/108/other/1907776 b/results/classifier/108/other/1907776 new file mode 100644 index 000000000..74fd37771 --- /dev/null +++ b/results/classifier/108/other/1907776 @@ -0,0 +1,73 @@ +graphic: 0.878 +boot: 0.772 +other: 0.753 +vnc: 0.740 +files: 0.728 +device: 0.687 +KVM: 0.658 +permissions: 0.643 +PID: 0.638 +semantic: 0.624 +network: 0.613 +performance: 0.592 +socket: 0.521 +debug: 0.491 + +Mounting VFat drive yields error messages. + +Mounting a virtual Fat drive results in error messages (see attached image). + +* https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +The "drive" is however mounted, and as a test, saving a text file to the drive is successfully stored in the directory `/tmp`, which can be read after shutdown of Qemu. + + Archlinux 5.9.11-arch2-1 (64-bit) + qemu-headless 5.1.0-3 + + qemu-system-x86_64 -boot order=d -name test \ + -enable-kvm -m 2G -cpu host -k sv \ + -daemonize \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \ + -drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \ + -vnc :1 \ + -cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \ + -drive format=raw,index=0,media=disk,file=~/vm/qemu.raw + + + +I have just noticed that the error does not appear when mounting the VFat drive in the installed instance of Arch Linux. The reported error messages occurred when using the "LiveUSB". + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1907817 b/results/classifier/108/other/1907817 new file mode 100644 index 000000000..387580212 --- /dev/null +++ b/results/classifier/108/other/1907817 @@ -0,0 +1,67 @@ +other: 0.814 +vnc: 0.798 +KVM: 0.754 +permissions: 0.711 +graphic: 0.701 +performance: 0.693 +debug: 0.688 +files: 0.683 +device: 0.681 +network: 0.665 +semantic: 0.656 +PID: 0.651 +socket: 0.639 +boot: 0.609 + +qemu-aarch64 tcg assertion v5.2.0 + +After updating to 5.2 I am getting following assertion error: +qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & max_align) == 0' failed. + +I think it was introduced by commit: e2e7168a214b0ed98dc357bba96816486a289762 + +Becasue before this change, in function simd_desc only maxsz % 8 == 0 was checked, but after this change qemu check for following: + +max_align = maxsz >= 16 ? 15 : 7; +tcg_debug_assert((maxsz & max_align) == 0); <--- here assertion happens + +in my case maxsz=56. + + +Whole backtrace: +#4 0x0000004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at ../tcg/tcg-op-gvec.c:54 +#5 0x0000004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at ../tcg/tcg-op-gvec.c:89 +#6 0x0000004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630 +#7 0x00000040003164d0 in expand_clr (dofs=3144, maxsz=56) at ../tcg/tcg-op-gvec.c:679 +#8 0x0000004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538 +#9 0x0000004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at ../target/arm/translate-a64.c:592 +#10 0x0000004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at ../target/arm/translate-a64.c:600 +--Type <RET> for more, q to quit, c to continue without paging-- +#11 0x0000004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at ../target/arm/translate-a64.c:608 +#12 0x0000004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, itof=true, rmode=0, scale=64, sf=0, type=0) + at ../target/arm/translate-a64.c:6988 +#13 0x0000004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7299 +#14 0x0000004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7389 +#15 0x000000400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:14494 +#16 0x000000400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) at ../target/arm/translate-a64.c:14663 +#17 0x000000400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823 +#18 0x00000040002e8630 in translator_loop (ops=0x4000902e00 <aarch64_translator_ops>, db=0x40021a8180, cpu=0x7fac59b63150, + tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103 +#19 0x00000040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512) + at ../target/arm/translate.c:9283 +#20 0x00000040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, cs_base=0, flags=2148544819, cflags=-16777216) + at ../accel/tcg/translate-all.c:1744 +#21 0x000000400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414 +--Type <RET> for more, q to quit, c to continue without paging-- +#22 0x000000400036b040 in cpu_exec (cpu=0x7fac59b63150) at ../accel/tcg/cpu-exec.c:770 +#23 0x0000004000113a90 in cpu_loop (env=0x7fac59b6b490) at ../linux-user/aarch64/cpu_loop.c:84 +#24 0x00000040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) at ../linux-user/main.c:864 + +Proposed patch: +https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04150.html + +I can confirm this patch fixes the issue + +Fix now in master as commit 6d3ef04893bde -- will be in next QEMU release. + + diff --git a/results/classifier/108/other/1907909 b/results/classifier/108/other/1907909 new file mode 100644 index 000000000..f6b82b319 --- /dev/null +++ b/results/classifier/108/other/1907909 @@ -0,0 +1,79 @@ +other: 0.821 +KVM: 0.767 +device: 0.729 +graphic: 0.719 +performance: 0.700 +files: 0.673 +permissions: 0.672 +vnc: 0.666 +debug: 0.653 +semantic: 0.650 +PID: 0.615 +boot: 0.597 +socket: 0.546 +network: 0.545 + +assertion failure in am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/esp.c:402: void esp_do_dma(ESPState *): Assertion `s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen' failed. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fdd25dc4700 (LWP 28983))] +gdb-peda$ bt +#0 0x00007fdd3f8b5f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fdd3f8b78b1 in __GI_abort () at abort.c:79 +#2 0x00007fdd3f8a742a in __assert_fail_base (fmt=0x7fdd3fa2ea38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=file@entry=0x55b3e11a4f73 "../hw/scsi/esp.c", line=line@entry=0x192, function=function@entry=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:92 +#3 0x00007fdd3f8a74a2 in __GI___assert_fail (assertion=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=0x55b3e11a4f73 "../hw/scsi/esp.c", line=0x192, function=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:101 +#4 0x000055b3e0941441 in esp_do_dma (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:401 +#5 0x000055b3e0944261 in handle_ti (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:549 +#6 0x000055b3e093fdf9 in esp_dma_enable (s=0x55b3e49d1c88, irq=<optimized out>, level=<optimized out>) + at ../hw/scsi/esp.c:79 +#7 0x000055b3e0897930 in esp_pci_dma_write (pci=<optimized out>, saddr=<optimized out>, val=<optimized +out>) at ../hw/scsi/esp-pci.c:83 +#8 0x000055b3e0897930 in esp_pci_io_write (opaque=<optimized out>, addr=<optimized out>, val=0xcf, size=0x4) at ../hw/scsi/esp-pci.c:209 +#9 0x000055b3e0e8f798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#10 0x000055b3e0e8f58e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#11 0x000055b3e0e8f58e in memory_region_dispatch_write (mr=0x55b3e49d1b70, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#12 0x000055b3e0e21541 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=0xffffffcf, attrs=..., result=0x0) at ../memory_ldst.c.inc:382 +#13 0x00007fdcd84a4a7f in code_gen_buffer () +#14 0x000055b3e0e57da0 in cpu_tb_exec (cpu=0x55b3e3c33650, itb=<optimized out>) + at ../accel/tcg/cpu-exec.c:178 +#15 0x000055b3e0e589eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized +out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#16 0x000055b3e0e589eb in cpu_exec (cpu=0x55b3e3c33650) at ../accel/tcg/cpu-exec.c:771 +#17 0x000055b3e0e87b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#18 0x000055b3e0e87b9f in tcg_cpu_thread_fn (arg=0x55b3e3c33650) at ../accel/tcg/tcg-cpus.c:427 +#19 0x000055b3e115f775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#20 0x00007fdd3fc6f6db in start_thread (arg=0x7fdd25dc4700) at pthread_create.c:463 +#21 0x00007fdd3f998a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +To reproduce the assertion failure, please run the QEMU with the following command line. + + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + +It looks like this reproducer triggers the same bug as #1919036, as of 3f8d1885e + +Can you still reproduce the issue with QEMU v6.0? For me, the attached reproducer does not cause a crash anymore... + +As Alexander already wrote, this triggered the same bug as #1919036 which got fixed by commit 0ebb5fd80589835153a0c2baa1b8cc7a04e67a93. Since this is not reproducible anymore, I'm closing this bug now. If you still can reproduce it somehow, please open a new ticket in the new gitlab issue tracker. + diff --git a/results/classifier/108/other/1907938 b/results/classifier/108/other/1907938 new file mode 100644 index 000000000..6748c34cc --- /dev/null +++ b/results/classifier/108/other/1907938 @@ -0,0 +1,99 @@ +other: 0.928 +permissions: 0.900 +device: 0.892 +performance: 0.878 +graphic: 0.837 +files: 0.820 +debug: 0.810 +semantic: 0.806 +vnc: 0.784 +socket: 0.781 +PID: 0.778 +boot: 0.764 +network: 0.762 +KVM: 0.757 + +[OSS-Fuzz] Issue 28524 virtio-blk: ASSERT: !s->dataplane_started + + affects qemu + +=== Reproducer === + +cat << EOF |./qemu-system-i386 -display none -m 512M -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw -qtest stdio +outl 0xcf8 0x8000181f +outl 0xcfc 0xa044d79 +outl 0xcf8 0x80001802 +outl 0xcf8 0x80001804 +outl 0xcfc 0xb9045dff +outl 0xcf8 0x8000180e +outl 0xcfc 0xfb9465a +outl 0xf85 0x9e1ea5c2 +write 0x9f002 0x1 0x04 +write 0x9f004 0x1 0x04 +write 0x9e040 0x1 0x04 +write 0x9e043 0x1 0x01 +write 0x9e048 0x1 0x10 +write 0x9e04c 0x1 0x01 +write 0x9e04e 0x1 0x6e +write 0x1000004 0x1 0x01 +write 0x9e6e3 0x1 0x01 +write 0x9e6eb 0x1 0x04 +write 0x9e6ec 0x1 0x6e +write 0x9f006 0x1 0x04 +write 0x9f008 0x1 0x04 +write 0x9f00a 0x1 0x04 +outl 0xf8f 0xc +EOF + +=== Stack Trace === + +qemu-fuzz-i386: ../hw/block/virtio-blk.c:917: void virtio_blk_reset(VirtIODevice *): Assertion `!s->dataplane_started' failed. +==702068== ERROR: libFuzzer: deadly signal +#0 0x55bd6fc9f311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311) +#1 0x55bd6fbe83d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8) +#2 0x55bd6fbce413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413) +#3 0x7ff5241b813f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f) +#4 0x7ff523feddb0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 +#5 0x7ff523feddb0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7ff523fd7536 in abort stdlib/abort.c:79:7 +#7 0x7ff523fd740e in __assert_fail_base assert/assert.c:92:3 +#8 0x7ff523fe65b1 in __assert_fail assert/assert.c:101:3 +#9 0x55bd7116c435 in virtio_blk_reset hw/block/virtio-blk.c:917:5 +#10 0x55bd710c94a2 in virtio_reset hw/virtio/virtio.c:2001:9 +#11 0x55bd6ff0e0a5 in virtio_pci_reset hw/virtio/virtio-pci.c:1886:5 +#12 0x55bd6ff10686 in virtio_ioport_write hw/virtio/virtio-pci.c:339:13 +#13 0x55bd6ff10686 in virtio_pci_config_write hw/virtio/virtio-pci.c:456:9 +#14 0x55bd713fd025 in memory_region_write_accessor softmmu/memory.c:491:5 +#15 0x55bd713fca93 in access_with_adjusted_size softmmu/memory.c:552:18 +#16 0x55bd713fc2f0 in memory_region_dispatch_write softmmu/memory.c +#17 0x55bd70e4bf36 in flatview_write_continue softmmu/physmem.c:2759:23 +#18 0x55bd70e41bbb in flatview_write softmmu/physmem.c:2799:14 +#19 0x55bd70e41bbb in address_space_write softmmu/physmem.c:2891:18 +#20 0x55bd71153462 in cpu_outl softmmu/ioport.c:80:5 +#21 0x55bd712d586e in qtest_process_command softmmu/qtest.c:483:13 +#22 0x55bd712d35bf in qtest_process_inbuf softmmu/qtest.c:797:9 +#23 0x55bd712d3315 in qtest_server_inproc_recv softmmu/qtest.c:904:9 +#24 0x55bd71910df8 in qtest_sendf tests/qtest/libqtest.c:438:5 +#25 0x55bd71911fae in qtest_out tests/qtest/libqtest.c:952:5 +#26 0x55bd71911fae in qtest_outl tests/qtest/libqtest.c:968:5 +#27 0x55bd6fcd1aa2 in op_out tests/qtest/fuzz/generic_fuzz.c:395:13 +#28 0x55bd6fcd04e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17 +#29 0x55bd6fcc9723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28524 + + + +This still reproduces with the current git version of QEMU. + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/543 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/108/other/1907952 b/results/classifier/108/other/1907952 new file mode 100644 index 000000000..267ad5dd6 --- /dev/null +++ b/results/classifier/108/other/1907952 @@ -0,0 +1,197 @@ +semantic: 0.877 +permissions: 0.873 +performance: 0.871 +graphic: 0.852 +device: 0.847 +other: 0.846 +PID: 0.832 +socket: 0.831 +boot: 0.831 +network: 0.828 +debug: 0.823 +vnc: 0.754 +files: 0.742 +KVM: 0.664 + +qemu-system-aarch64: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0 + +I originally observed this on Debian packaged qemu 5.2 at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 + +Today I checked out the latest git source at +Sun, 13 Dec 2020 19:21:09 +0900 +and configured the source as follows: + +./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu \ + --localstatedir=/var --disable-blobs --disable-strip --localstatedir=/var \ + --libdir=/usr/lib/aarch64-linux-gnu \ + --firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu \ + --target-list=aarch64-softmmu,arm-softmmu --disable-werror \ + --disable-user --enable-gtk --enable-vnc +then executed "make" on an ARM64 (not an x86_64) host, +running the latest Debian testing. + +I did the following commands on an arm64 host with the Debian Installer Alpha 3 at +https://cdimage.debian.org/cdimage/bullseye_di_alpha3/arm64/iso-cd/debian-bullseye-DI-alpha3-arm64-netinst.iso + +#!/bin/sh + +ARCH=arm64 +IMAGE=`pwd`/qemu-disk-${ARCH}.qcow2 +CDROM=`pwd`/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso +rm -f $IMAGE +qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o preallocation=off $IMAGE 20G +cd /var/tmp +cp /usr/share/AAVMF/AAVMF_VARS.fd . +$HOME/qemu-git/qemu/build/qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 3072 -smp 2\ + -net nic,model=virtio -net user -object rng-random,filename=/dev/urandom,id=rng0 \ + -device virtio-rng-pci,rng=rng0,id=rng-device0 \ + -drive if=virtio,file=${IMAGE},index=0,format=qcow2,discard=unmap,detect-zeroes=unmap,media=disk \ + -drive if=virtio,file=${CDROM},index=1,format=raw,readonly=on,media=cdrom \ + -drive if=pflash,format=raw,unit=0,file=/usr/share/AAVMF/AAVMF_CODE.fd,readonly=on \ + -drive if=pflash,format=raw,unit=1,file=`pwd`/AAVMF_VARS.fd + +Then 4 arrow keys on the physical keyboard are received as just "^[". + +This symptom was not observed on qemu-system-x86_64. +This symptom was not observed with virt-manager on my arm64 host, neither. +This seems unique to -display gtk of qemu-system-aarch64. + +An easier way to reproduce the symptom was provided by Alper Nebi Yasak at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808#88 + +qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 1G -smp 2 \ + -kernel /boot/vmlinuz -initrd /boot/initrd.img \ + -append "break console=ttyAMA0" + +Then, run cat on the initramfs shell and see arrow keys result in ^[ . +For x86_64, it's console=ttyS0 and ^[[A etc. + + +This should be fixed already in head-of-git, by commit 8eb13bbbac08aa077e ; this will be in QEMU 6.0. + + +This bug was fixed in the package qemu - 1:6.0+dfsg-1~ubuntu3 + +--------------- +qemu (1:6.0+dfsg-1~ubuntu3) impish; urgency=medium + + * d/p/u/lp-1935617-target-ppc-Fix-load-endianness-for-lxvwsx-lxvdsx.patch: + fix TCG emulation for ppc64 (LP: #1935617) + +qemu (1:6.0+dfsg-1~ubuntu2) impish; urgency=medium + + * d/control: remove fuse2 trial-build (LP 1934510) + +qemu (1:6.0+dfsg-1~ubuntu1) impish; urgency=medium + + * Merge with Debian experimental, Among many other things this fixes LP Bugs: + (LP: #1907952) broken arrow keys in -display gtk on aarch64 + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-system-common.qemu-kvm.service: systemd unit to call + qemu-kvm-init + - d/qemu-system-common.install: install helper script + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm + - Distribution specific machine type + (LP: 1304107 1621042 1776189 1761372 1761372 1776189) + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types containing release versioned machine attributes + - d/qemu-system-x86.NEWS Info on fixed machine type defintions + for host-phys-bits=true + - Add an info about -hpb machine type in debian/qemu-system-x86.NEWS + - ubuntu-q35 alias added to auto-select the most recent q35 ubuntu type + - Enable nesting by default + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + [ No more strictly needed, but required for backward compatibility ] + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - Let qemu-utils recommend sharutils + - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490) + - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types + reference 256k path + - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to + handle incoming migrations from former releases. + - d/control-in: Disable capstone disassembler library support (universe) + - d/qemu-system-x86.README.Debian: add info about updated nesting changes + - d/control*, d/rules: disable xen by default, but provide universe + package qemu-system-x86-xen as alternative + [includes compat links changes of 5.0-5ubuntu4] + - Fix upgrade module handling (LP 1905377) + --enable-module-upgrades for qemu-xen which doesn't exist in Debian + * Dropped Changes [in 6.0]: + - d/p/ubuntu/lp-1907789-build-no-pie-is-no-functional-liker-flag.patch: fix + ld usage of -no-pie (LP 1907789) + - d/p/u/lp-1916230-hw-s390x-fix-build-for-virtio-9p-ccw.patch: fix + virtio-9p-ccw being missing (LP 1916230) + - d/p/u/lp-1916705-disas-Fix-build-with-glib2.0-2.67.3.patch: Fix FTFBS due + to glib2.0 >=2.67.3 (LP 1916705) + - d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails + on some HW/Guest combinations e.g. Windows 10 on Threadripper chips + (LP 1921754) + - d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support + (LP 1921880) + - d/p/u/lp-1922010-linux-user-s390x-Use-the-guest-pointer-for-the-sigre*: + fix go in qemu-s390x-static (LP 1922010) + * Dropped Changes [in Debian]: + - Allow qemu to load old modules post upgrade (LP 1847361) + - Drop d/qemu-block-extra.*.in, d/qemu-system-gui.*.in + - d/rules: Drop generating package version into maintainer scripts + * Dropped Changes [No more needed >21.04]: + - d/qemu-system-gui.prerm: add no-op prerm to overcome upgrade issues on + the bad old prerm (LP 1906245 1905377) + * Added Changes + - Disable fuse export (universe dependency) + - d/p/ubuntu/enable-svm-by-default.patch: update to match v6.0 + - d/p/ubuntu/define-ubuntu-machine-types.patch: add ubuntu machine types + for v6.0 + - d/p/ubuntu/lp-1929926-*: avoid segfaults by uretprobes (LP: #1929926) + - Ease the use of module retention on upgrades (LP: #1913421) + - d/run-qemu.mount, d/rules: provide run-qemu.mount in qemu-block-extra + - d/rules: only save modules if /run/qemu isn't noexec + - d/rules: clear all (current and former) modules on purge + - debian/qemu-block-extra.postinst: enable mount unit on install/upgrade + - d/control: qemu 6.0 broke libvirt <7.2 add a breaks to avoid partial + upgrade issues (LP: #1932264) + - Enable SDL as secondary UI backend (LP: #1256185) + - d/control: add build dependency libsdl2-dev + - d/control: enable sdl graphics on build + - d/qemu-system-gui.install: add ui-sdl.so + - d/control: add runtime dependency to libgl1 + - d/rules: qemu-system-x86-xen builds modules as well now (follows the + other packages) + +qemu (1:6.0+dfsg-1~exp0) experimental; urgency=medium + + * new upstream release + * remove obsolete patches, refresh use-fixed-data-path.patch + * use libncurses-dev, not old libncursesw5-dev + * enable fuse export (and build-depend on libfuse3-dev) + * install (new) manpages for qemu-storage-daemon + * enable new hexagon qemu-user target + * two patches to fix 3 new spelling mistakes + * remove now-unused shared-library-lacks-prerequisites lintian-overrides + for qemu-user-static + +qemu (1:5.2+dfsg-10) unstable; urgency=medium + + * 5 sdhci fixes from upstream: + dont-transfer-any-data-when-command-time-out.patch + dont-write-to-SDHC_SYSAD-register-when-transfer-is-in-progress.patch + correctly-set-the-controller-status-for-ADMA.patch + limit-block-size-only-when-SDHC_BLKSIZE-register-is-writable.patch + reset-the-data-pointer-of-s-fifo_buffer-when-a-different-block-size...patch + (Closes: #986795, #970937, CVE-2021-3409, CVE-2020-17380, CVE-2020-25085) + * mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch + fix possible use-after-free in mptsas_free_request + (Cloese: #984449, CVE-2021-3392) + + -- Christian Ehrhardt <email address hidden> Tue, 13 Jul 2021 09:34:55 +0200 + diff --git a/results/classifier/108/other/1907953 b/results/classifier/108/other/1907953 new file mode 100644 index 000000000..3867e4a2a --- /dev/null +++ b/results/classifier/108/other/1907953 @@ -0,0 +1,21 @@ +vnc: 0.737 +device: 0.724 +semantic: 0.713 +other: 0.695 +performance: 0.477 +graphic: 0.439 +debug: 0.414 +files: 0.383 +network: 0.315 +boot: 0.263 +permissions: 0.220 +socket: 0.139 +PID: 0.123 +KVM: 0.029 + +pkg install qemu-system-x86_64 não funciona qemu 5.2.0 + +A qemu funcionava mais quando atualizei para 5.2.0 não iniciar o Windows só fica tela preta quero voltar para anterior mais não consigo + +Sorry, please write bug reports in proper English. + |