diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1911 | 55 | ||||
| -rw-r--r-- | results/classifier/108/other/1911075 | 97 | ||||
| -rw-r--r-- | results/classifier/108/other/1911188 | 70 | ||||
| -rw-r--r-- | results/classifier/108/other/1911351 | 122 | ||||
| -rw-r--r-- | results/classifier/108/other/1911666 | 93 | ||||
| -rw-r--r-- | results/classifier/108/other/1911839 | 88 |
6 files changed, 525 insertions, 0 deletions
diff --git a/results/classifier/108/other/1911 b/results/classifier/108/other/1911 new file mode 100644 index 00000000..9df37279 --- /dev/null +++ b/results/classifier/108/other/1911 @@ -0,0 +1,55 @@ +other: 0.861 +graphic: 0.848 +KVM: 0.836 +semantic: 0.791 +vnc: 0.787 +debug: 0.779 +permissions: 0.769 +device: 0.723 +performance: 0.672 +boot: 0.629 +PID: 0.597 +socket: 0.523 +network: 0.512 +files: 0.373 + +abnormal segfaults inside qemu-system-riscv64 +Description of problem: +3 tests of Cockatrice segfaults in qemu-system-riscv64 emulator. This is similar to a regression of qemu-riscv64-static I reported: #1908. +But for qemu-system-riscv64, it doesn't looks like a recent regression because qemu 7.2.1 also fails. +Steps to reproduce: +To save the time on reproducing this bug, [I uploaded the zstd compressed qcow2 image to google drive](https://drive.google.com/file/d/1-2Wtmq4MlGvTLjmQ7P5vAvNlWg8--jjT/view?usp=sharing). It contains the whole environment, cockatrice source code and built tests. + +The password of the root user is `archriscv`. + +1. Setup Arch Linux riscv environment: https://github.com/CoelacanthusHex/archriscv-scriptlet https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-using-qemu-system +2. Start it(with the commandline above, in the boot menu, choose `2: Linux linux (fallback initramfs)`) and building cockatrice with tests in it. +3. Run tests (/root/Cockatrice/build/tests/loading_from_clipboard/loading_from_clipboard_test, /root/Cockatrice/build/tests/carddatabase/filter_string_test, /root/Cockatrice/build/tests/carddatabase/carddatabase_test) +4. The tests segfault, which is unexpected. +Additional information: +The tests segfault at exactly the same instruction as in #1908: + +``` +┌──────────────────────────────────────────────────────────────────────────────┐ +│ > 0x7ffff2cba928 lhu a2,1248(a2) │ +│ 0x7ffff2cba92c and a0,a0,127 │ +│ 0x7ffff2cba930 sll a2,a2,0x7 │ +│ 0x7ffff2cba934 add a0,a0,a2 │ +│ 0x7ffff2cba938 lui t2,0xf8000 │ +│ 0x7ffff2cba93c lui a2,0xf5de2 │ +│ 0x7ffff2cba940 add a2,a2,-1824 │ +│ 0x7ffff2cba944 sll t2,t2,0x14 │ +│ 0x7ffff2cba948 xor a2,a2,t2 │ +│ 0x7ffff2cba94c sll t2,a0,0x1 │ +│ 0x7ffff2cba950 add a2,a2,t2 │ +│ 0x7ffff2cba954 lhu a2,0(a2) │ +│ 0x7ffff2cba958 sll a0,a2,0x3 │ +└──────────────────────────────────────────────────────────────────────────────┘ +multi-thre Thread 0x7ffff2cbe0 In: L?? PC: 0x7ffff2cba928 +(gdb) bt +#0 0x00007ffff2cba928 in () +``` + +It might suggest that 2d708164e0475064e0e2167bd73e8570e22df1e0 is not the true cause of #1908 and this bug shares the same underlying cause with #1908. + +Commit 2d708164e0475064e0e2167bd73e8570e22df1e0 LGTM, although it seems that it is copied from the loongarch one and the author forgot to update [the file header](https://gitlab.com/qemu-project/qemu/-/blob/2d708164e0475064e0e2167bd73e8570e22df1e0/linux-user/riscv/target_mman.h#L1-6). diff --git a/results/classifier/108/other/1911075 b/results/classifier/108/other/1911075 new file mode 100644 index 00000000..e6078bc8 --- /dev/null +++ b/results/classifier/108/other/1911075 @@ -0,0 +1,97 @@ +other: 0.922 +debug: 0.867 +performance: 0.863 +permissions: 0.862 +device: 0.854 +graphic: 0.851 +vnc: 0.793 +semantic: 0.791 +KVM: 0.760 +boot: 0.749 +files: 0.745 +PID: 0.726 +socket: 0.689 +network: 0.670 + +[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines + +=== Reproducer === +while true; do cat << EOF; done | ./qemu-system-i386 -machine q35 -nodefaults -nographic -qtest stdio -accel qtest +outl 0xcf8 0x8000fa27 +outl 0xcfc 0x37414537 +outl 0xcf8 0x8000fa01 +outl 0xcfc 0x4606ce74 +writew 0x37000f01 0x215a +writeq 0x37000100 0xfffaf +writeq 0x37000115 0xffff373d27004037 +outl 0xcf8 0x8000fa01 +outl 0xcfc 0x4606ce74 +writeq 0x370000ff 0x3700011500 +writeq 0x37000115 0xc41ffffff035a5a +outl 0xcf8 0x8000ea04 +outb 0xcfc 0x15 +outl 0xcf8 0x8000ea00 +outw 0xcfc 0x5a1f +writeq 0x37000115 0x100007765746972 +writeq 0x37000115 0xbf00000000000000 +outl 0xcf8 0x8000ea04 +outb 0xcfc 0x15 +outl 0xcf8 0x8000fa46 +outb 0xcfc 0xff +clock_step +writeq 0x37000115 0xaf +writeq 0x37000115 0x6301275541af7415 +writeq 0x37000115 0xafaf5a5a743715 +outb 0x64 0xfe +EOF + +=== Stack Trace === +==887446==ERROR: UndefinedBehaviorSanitizer: stack-overflow on address 0x7ffe567cae0c (pc 0x7fdd9100819e bp 0x7ffe567cb2b0 sp 0x7ffe567cad40 T887446) + +#0 vfprintf +#1 fprintf +#2 ahci_mem_write /src/qemu/hw/ide/ahci.c:468:9 +#3 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#4 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#5 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#6 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#7 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#8 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#9 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9 +#10 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5 +#11 map_page /src/qemu/hw/ide/ahci.c:249:9 +#12 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5 +#13 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14 +#14 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9 +#15 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9 +#16 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#17 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#18 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#19 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#20 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#21 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#22 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9 +#23 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5 +#24 map_page /src/qemu/hw/ide/ahci.c:249:9 +#25 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5 +#26 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14 +#27 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9 +#28 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9 +... Repeat until we run out of stack + +Having a quick look, the problem might be in ahci_cond_start_engines() +which calls ahci_map_clb_address(), then ahci_map_fis_address() fails +and we return without calling ahci_unmap_clb_address(). + +And ahci_port_write(AHCI_PORT_REG_CMD) doesn't check +ahci_cond_start_engines() return value, calling +ahci_init_d2h() even if former failed. + + +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/62 + + diff --git a/results/classifier/108/other/1911188 b/results/classifier/108/other/1911188 new file mode 100644 index 00000000..49446183 --- /dev/null +++ b/results/classifier/108/other/1911188 @@ -0,0 +1,70 @@ +device: 0.912 +graphic: 0.902 +semantic: 0.853 +files: 0.809 +other: 0.765 +PID: 0.761 +permissions: 0.729 +debug: 0.711 +socket: 0.710 +network: 0.697 +performance: 0.692 +vnc: 0.639 +boot: 0.638 +KVM: 0.485 + +qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument + +QEMU emulator version 4.2.1 (qemu-4.2.1-1.fc32) on Fedora 32. + +When writing a script to start qemu automatically, I ran into a very confusing error message due to a bug in my script and had trouble understanding it. I isolated the problem to the following: + +$ qemu-system-x86_64 "" +qemu-system-x86_64: Initialization of device ide-hd failed: Device needs media, but drive is empty + +As you can see, running qemu with an empty argument prints a seemingly random and unrelated error message about an ide-hd device, and the program immediately exits with code 1. This happens when an empty argument appears anywhere in the arguments list, always causing the program to immediately die with this error. + +This is a simply baffling message to be encountering when the problem is really an empty argument. + +Expected behaviour: Either flatly ignore the empty argument, or at most trigger a warning (eg, "warning: saw empty argument"). It should not at all prevent the program from running. + +If QEMU receives an argument that isn't an option flag, then it considers it to be the path to a disk. The block code treats the empty string as indicating that no backing file should be opened for the device. This only makes sense for devices that support removable media (ie CDROM, floppy), hence getting an error message for the ide-hd disk. + +So weird as this message might seem, I believe it does ultimately make sense, and I don't think we can just ignore the empty string without potentially breaking other things. + +Thanks for the quick reply Daniel. I've looked at the qemu man page many times but somehow never noticed that it can take one non-option argument alongside any other options. That does explain what is going on here. In that case I'm not going to push for a potentially breaking change. + +Perhaps it would still be beneficial to emit a warning about the empty string, at least when it has occurred in conjunction with a non-removable drive (I suppose one is created automatically if no other options are present?) which doesn't make sense to get such a path. I feel like the scenario in which it is intended might be less common than the scenario in which it has happened accidentally. Maybe I'm biased though ;) + +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/1911351 b/results/classifier/108/other/1911351 new file mode 100644 index 00000000..73666646 --- /dev/null +++ b/results/classifier/108/other/1911351 @@ -0,0 +1,122 @@ +other: 0.855 +permissions: 0.842 +graphic: 0.839 +semantic: 0.838 +debug: 0.816 +device: 0.811 +performance: 0.802 +PID: 0.782 +network: 0.775 +vnc: 0.742 +files: 0.736 +boot: 0.735 +socket: 0.735 +KVM: 0.709 + +x86-64 MTTCG Does not update page table entries atomically + +It seems like the qemu tcg code for x86-64 doesn't write the access and dirty flags of the page table entries atomically. Instead, they first read the entry, see if they need to set the page table entry, and then overwrite the entry. So if you have two threads running at the same time, one accessing the virtual address over and over again, and the other modifying the page table entry, it is possible that after the second thread modifies the page table entry, qemu overwrites the value with the old page table entry value, with the access/dirty flags set. + +Here's a unit test that reproduces this behavior: + +https://github.com/mvanotti/kvm-unit-tests/commit/09f9722807271226a714b04f25174776454b19cd + +You can run it with: + +``` +/usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \ +-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \ +-vnc none -serial stdio -device pci-testdev \ +-smp 4 -machine q35 --accel tcg,thread=multi \ +-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf +``` + +Expected output (failure): + +``` +kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf +enabling apic +enabling apic +enabling apic +enabling apic +paging enabled +cr0 = 80010011 +cr3 = 627000 +cr4 = 20 +found 4 cpus +PASS: Need more than 1 CPU +Detected overwritten PTE: + want: 0x000000000062e007 + got: 0x000000000062d027 +FAIL: PTE not overwritten +PASS: All Reads were zero +SUMMARY: 3 tests, 1 unexpected failures +``` + +This bug has allows user-to-root privilege escalation inside the guest VM: if the user is able overwrite an entry that belongs to a second-to-last level page table, and is able to allocate the referenced page, then the user would be in control of a last-level page table, being able to map any memory they want. This is not uncommon in situations where memory is being decomitted. + +Yeah, it's a long standing API deficiency inside QEMU that we don't have a way to do atomic modifications in things like page-table-walk code: mostly you don't notice unless you go looking for it, but we really ought to fix this. Thanks for the unit test. + + +Not strictly i386 specific -- any arch that wants to do read-modify-update to its page tables runs into this. There are some not-yet-implemented Arm architecture extensions that require this, and likely other archs too. + + +We only tested it on x86-64 and aarch64, but we couldn't repro on arm. It is possible that this affects other platforms as well, but note that this is specifically mentioned in the qemu wiki as one of the cases that should be covered when porting mttcg to a new platform: https://wiki.qemu.org/Features/tcg-multithread + +BTW, the RISC-V MMU code _does_ get this right and the model could be followed by the x86 version - - something like https://github.com/vsrinivas/qemu/commit/1efa7dc689c4572d8fe0880ddbe44ec22f8f4348, (but with more compiling + working) might solve this problem and more closely model h/w. + +On Tue, 2 Feb 2021 at 05:07, Venkatesh Srinivas +<email address hidden> wrote: +> BTW, the RISC-V MMU code _does_ get this right and the model could be +> followed by the x86 version - - something like +> https://github.com/vsrinivas/qemu/commit/1efa7dc689c4572d8fe0880ddbe44ec22f8f4348, +> (but with more compiling + working) might solve this problem and more +> closely model h/w + +target/i386 is the wrong place to put the fix, though: +the abstraction layers for working with AddressSpaces need to +provide atomic operations and then under the hood do the right +thing to implement them. target-specific code shouldn't need +to manually do the translation, fish out a MemoryRegion, +check whether it's really host RAM, and so on. + +thanks +-- PMM + + +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. + + +This issue has been migrated to gitlab issue #279. See https://gitlab.com/qemu-project/qemu/-/issues/279 + +Closing issue as it has been migrated to https://gitlab.com/qemu-project/qemu/-/issues/279 + +Closing issue as it has been migrated to https://gitlab.com/qemu-project/qemu/-/issues/279 + diff --git a/results/classifier/108/other/1911666 b/results/classifier/108/other/1911666 new file mode 100644 index 00000000..e97caaed --- /dev/null +++ b/results/classifier/108/other/1911666 @@ -0,0 +1,93 @@ +device: 0.838 +vnc: 0.829 +other: 0.825 +KVM: 0.821 +permissions: 0.814 +debug: 0.807 +graphic: 0.790 +performance: 0.790 +semantic: 0.787 +PID: 0.772 +network: 0.760 +files: 0.752 +boot: 0.727 +socket: 0.726 + +ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability + +-- CVSS ----------------------------------------- + +7.5: AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H + +-- ABSTRACT ------------------------------------- + +Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: +QEMU - QEMU + +-- VULNERABILITY DETAILS ------------------------ + +Version tested:5.0.0-rc3 +Installer file:qemu-5.0.0-rc3.tar.xz +Platform tested:ubuntu 18.04 x64 desktop +Analysis Basically v9fs* functions called from guest kernel are executed under specific thread(I call it main thread later). But when it calls some file related system calls, qemu uses its own coroutine thread(worker thread). Then it returns(yield return) without waiting result of system call and start to execute next v9fs* function. + +In v9fsmarkfidsunreclaim() function, it stores fidlist member (head of singly linked list) to its stack. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L506 + +And if it uses coroutine, it restore fid_list from stack and restart whole loop. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L526 + +v9fsclunk() function calls clunkfid() which unlink fid from list, and free it. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L2060-L2091 + +So if v9fsclunk() is called while v9fsmarkfidsunreclaim()'s coroutine is being executed, it restores "FREED" fidp from stack and use it. + +it can be reproduced with the qemu binary, which is given +it can also be reproduced with own ASAN build (5.0.0-rc3 and 4.2.0 are tested) + +../qemu-5.0.0-rc3/x86_64-softmmu/qemu-system-x86_64 -M pc -kernel ./bzImage -initrd ./rootfs.cpio -append "root=/dev/ram console=tty1 console=ttyS0 rdinit=/bin/sh" -nographic -enable-kvm -fsdev local,id=test_dev,path=/home/xxx/sandbox,security_model=none -device virtio-9p-pci,fsdev=test_dev,mount_tag=victim_tag + +$ ./do.sh +expected ASAN report is printed +the race is in coroutine, so the threads are the same one + +================================================================= + ==46645==ERROR: AddressSanitizer: heap-use-after-free on address 0x610000047948 at pc 0x5563d8c28f0f bp0 +READ of size 2 at 0x610000047948 thread T0 + + #0 0x5563d8c28f0e in v9fs_mark_fids_unreclaim hw/9pfs/9p.c:508 + #1 0x5563d8c3e9e3 in v9fs_remove hw/9pfs/9p.c:2988 + #2 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #3 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + 0x610000047948 is located 8 bytes inside of 192-byte region [0x610000047940,0x610000047a00) freed by thread T0 here: + + #0 0x7fadafa5f7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) + #1 0x5563d8c27a60 in free_fid hw/9pfs/9p.c:371 + #2 0x5563d8c27fcc in put_fid hw/9pfs/9p.c:396 + #3 0x5563d8c37267 in v9fs_clunk hw/9pfs/9p.c:2085 + #4 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #5 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + +previously allocated by thread T0 here: + #0 0x7fadafa5fd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) + #1 0x7fadaf0c8b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) + #2 0x5563d8c30ecc in v9fs_attach hw/9pfs/9p.c:1412 + #3 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #4 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + +This vulnerability was discovered by: + +Ryota Shiga(@Garyo) of Flatt Security working with Trend Micro Zero Day Initiative + +Requesting a CVE... + +'CVE-2021-20181' is assigned to this issue by Red Hat Inc. + +Fixed by commit 89fbea8737e ("9pfs: Fully restart unreclaim loop (CVE-2021-20181)"). + + diff --git a/results/classifier/108/other/1911839 b/results/classifier/108/other/1911839 new file mode 100644 index 00000000..a8d3dbe5 --- /dev/null +++ b/results/classifier/108/other/1911839 @@ -0,0 +1,88 @@ +other: 0.914 +device: 0.891 +performance: 0.876 +permissions: 0.843 +graphic: 0.813 +boot: 0.812 +semantic: 0.789 +vnc: 0.775 +network: 0.761 +files: 0.753 +debug: 0.724 +socket: 0.718 +KVM: 0.718 +PID: 0.655 + +[OSS-Fuzz] Issue 29586 e1000e: Memcpy-param-overlap in flatview_write_continue + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -M q35 -accel qtest \ +-qtest stdio -nographic -nodefaults -device \ +e1000e,netdev=net0 -netdev user,id=net0 +outl 0xcf8 0x80000811 +outl 0xcfc 0x5ac600 +outl 0xcf8 0x80000801 +outl 0xcfc 0x26000000 +write 0x5ac60100 0x4 0x56000302 +write 0x5ac6011a 0x2 0x1006 +write 0x5ac60120 0x1 0x25 +write 0x5ac6042a 0x2 0x4048 +write 0x5ac60431 0x1 0x04 +write 0x4240 0x1 0xff +write 0x4241 0x1 0x01 +write 0x4249 0x1 0xf5 +write 0x1ff 0x1 0x11 +write 0x5ac60401 0x1 0x12 +write 0x5ac6043a 0x2 0x3000 +write 0x5ac60112 0x2 0xf090 +write 0x5ac60430 0x1 0x0 +write 0x239 0x1 0xff +write 0x2bb 0x1 0x41 +write 0x9531 0x1 0xff +write 0x9532 0x1 0xff +write 0x9533 0x1 0xff +write 0x9534 0x1 0xff +write 0x9535 0x1 0xff +write 0x9536 0x1 0xff +write 0x9537 0x1 0xff +write 0x5ac60403 0x1 0x12 +EOF + +=== Stack Trace === +==1364==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x7f90b7e00025,0x7f90b7e00604) and [0x7f90b7e00225, 0x7f90b7e00804) overlap +#0 __asan_memcpy /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 +#1 flatview_write_continue /src/qemu/softmmu/physmem.c:2764:13 +#2 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#3 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#4 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 +#5 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 +#6 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 +#7 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 +#8 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 +#9 e1000e_write_to_rx_buffers /src/qemu/hw/net/e1000e_core.c:1405:9 +#10 e1000e_write_packet_to_guest /src/qemu/hw/net/e1000e_core.c:1575:21 +#11 e1000e_receive_iov /src/qemu/hw/net/e1000e_core.c:1702:9 +#12 e1000e_nc_receive_iov /src/qemu/hw/net/e1000e.c:214:12 +#13 net_tx_pkt_sendv /src/qemu/hw/net/net_tx_pkt.c:556:9 +#14 net_tx_pkt_send /src/qemu/hw/net/net_tx_pkt.c:633:9 +#15 net_tx_pkt_send_loopback /src/qemu/hw/net/net_tx_pkt.c:646:11 +#16 e1000e_tx_pkt_send /src/qemu/hw/net/e1000e_core.c:657:16 +#17 e1000e_process_tx_desc /src/qemu/hw/net/e1000e_core.c:736:17 +#18 e1000e_start_xmit /src/qemu/hw/net/e1000e_core.c:927:9 +#19 e1000e_set_tctl /src/qemu/hw/net/e1000e_core.c:2424:9 +#20 e1000e_core_write /src/qemu/hw/net/e1000e_core.c:3256:9 +#21 e1000e_mmio_write /src/qemu/hw/net/e1000e.c:110:5 +#22 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#23 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#24 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#25 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#26 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#27 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#28 __wrap_qtest_writeq /src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9 +#29 op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:479:13 +#30 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29586 + +This is still reproducible with the current git version (commit 7fe7fae8b48e3f9c647fd685e5155ebc8e6fb84d) and clang with ASAN enabled. + |