summary refs log tree commit diff stats
path: root/results/classifier/108/other/1050
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/105087
-rw-r--r--results/classifier/108/other/105069499
2 files changed, 186 insertions, 0 deletions
diff --git a/results/classifier/108/other/1050 b/results/classifier/108/other/1050
new file mode 100644
index 000000000..4593e523e
--- /dev/null
+++ b/results/classifier/108/other/1050
@@ -0,0 +1,87 @@
+graphic: 0.857
+other: 0.843
+performance: 0.839
+device: 0.805
+debug: 0.787
+semantic: 0.770
+permissions: 0.767
+network: 0.736
+PID: 0.734
+KVM: 0.707
+files: 0.702
+socket: 0.701
+vnc: 0.669
+boot: 0.651
+
+[BUG] heap-buffer-overflow in sifive_plic_create
+Description of problem:
+I run check-qtest-riscv64 in ubuntu20.04, and got a heap-buffer-overflow report with address sanitizer   
+HEAD: 7077fcb9b68f058809c9dd9fd1dacae1881e886c
+Steps to reproduce:
+run 
+`G_TEST_DBUS_DAEMON=/root/o/sources/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=58 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_BINARY=./qemu-system-riscv64 /root/o/sources/qemu/build/tests/qtest/test-hmp --tap -k`
+Additional information:
+I think is because on some conditions when after `j++(hw/intc/sifive_plic.c:458)`, it accesses `plic->addr_config[j](hw/intc/sifive_plic.c:463)`  and results in heap-overflow.  
+I tried to modify `hw/intc/sifive_plic.c:463` to else-if, then the report gone.  
+Could you please have a check.  
+```
+==63425==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000031624 at pc 0x561afe157d54 bp 0x7ffcd8aef510 sp 0x7ffcd8aef500
+READ of size 4 at 0x602000031624 thread T0
+    #0 0x561afe157d53 in sifive_plic_create ../hw/intc/sifive_plic.c:463
+    #1 0x561afdc0ac7f in sifive_e_soc_realize ../hw/riscv/sifive_e.c:207
+    #2 0x561afe6698fb in device_set_realized ../hw/core/qdev.c:531
+    #3 0x561afe679b90 in property_set_bool ../qom/object.c:2273
+    #4 0x561afe681c7f in object_property_set ../qom/object.c:1408
+    #5 0x561afe68b763 in object_property_set_qobject ../qom/qom-qobject.c:28
+    #6 0x561afe682535 in object_property_set_bool ../qom/object.c:1477
+    #7 0x561afdc0a601 in sifive_e_machine_init ../hw/riscv/sifive_e.c:91
+    #8 0x561afd34d608 in machine_run_board_init ../hw/core/machine.c:1427
+    #9 0x561afda49697 in qemu_init_board ../softmmu/vl.c:2610
+    #10 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2706
+    #11 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2699
+    #12 0x561afda504ee in qemu_init ../softmmu/vl.c:3737
+    #13 0x561afd1cf4ae in qemu_main ../softmmu/main.c:35
+    #14 0x561afd1cf4ae in main ../softmmu/main.c:45
+    #15 0x7f9d13bf3082 in __libc_start_main ../csu/libc-start.c:308
+    #16 0x561afd1de78d in _start (/root/o/sources/qemu/build/qemu-system-riscv64+0x271378d)
+
+0x602000031624 is located 8 bytes to the right of 12-byte region [0x602000031610,0x60200003161c)
+allocated by thread T0 here:
+    #0 0x7f9d15026808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
+    #1 0x7f9d14a84e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/intc/sifive_plic.c:463 in sifive_plic_create
+Shadow bytes around the buggy address:
+  0x0c047fffe270: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa
+  0x0c047fffe280: fa fa 05 fa fa fa 07 fa fa fa fd fa fa fa 02 fa
+  0x0c047fffe290: fa fa 00 01 fa fa fd fd fa fa fd fa fa fa fd fd
+  0x0c047fffe2a0: fa fa 00 02 fa fa 00 02 fa fa 05 fa fa fa 07 fa
+  0x0c047fffe2b0: fa fa 00 01 fa fa 07 fa fa fa 05 fa fa fa 07 fa
+=>0x0c047fffe2c0: fa fa 00 04[fa]fa 04 fa fa fa 00 00 fa fa 00 00
+  0x0c047fffe2d0: fa fa 00 00 fa fa fd fd fa fa 00 03 fa fa fd fd
+  0x0c047fffe2e0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd
+  0x0c047fffe2f0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd
+  0x0c047fffe300: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fa
+  0x0c047fffe310: fa fa fd fd fa fa 00 03 fa fa fd fd fa fa 00 03
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07 
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+==63425==ABORTING
+```
diff --git a/results/classifier/108/other/1050694 b/results/classifier/108/other/1050694
new file mode 100644
index 000000000..ea2c4ecd6
--- /dev/null
+++ b/results/classifier/108/other/1050694
@@ -0,0 +1,99 @@
+debug: 0.884
+permissions: 0.870
+PID: 0.865
+performance: 0.864
+semantic: 0.864
+graphic: 0.863
+device: 0.857
+other: 0.854
+boot: 0.843
+socket: 0.843
+files: 0.836
+vnc: 0.833
+KVM: 0.818
+network: 0.807
+
+Interrupt 0xffffffff when debug is turned on
+
+Hi,
+
+I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log:
+
+qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G
+
+Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line):
+Servicing hardware INT=0xffffffff
+1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000
+EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780
+ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768
+EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
+SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+LDT=0000 00000000 00000000 00008200 DPL=0 LDT
+TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl
+GDT= 00127760 00000027
+IDT= 00122f40 000007ff
+CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000
+DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
+DR6=ffff0ff0 DR7=00000400
+CCS=00000024 CCD=0012b75c CCO=ADDL 
+EFER=0000000000000000
+check_exception old: 0xffffffff new 0xd
+2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000
+EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780
+ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768
+EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
+SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
+LDT=0000 00000000 00000000 00008200 DPL=0 LDT
+TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl
+GDT= 00127760 00000027
+IDT= 00122f40 000007ff
+CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000
+DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
+DR6=ffff0ff0 DR7=00000400
+CCS=00000024 CCD=0012b75c CCO=ADDL 
+EFER=0000000000000000
+
+To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from.
+
+Some additional information:
+
+
+This command works:
+
+qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G
+
+
+This command works:
+
+qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G
+
+
+And, as above, this does not:
+
+qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G
+
+
+[adam@os-development ~]$ qemu-system-i386 -version
+QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard
+
+
+Attached is an image as a test case.  Please let me know if you need any additional information.
+
+
+
+Original conversation about this issue on osdev.org: http://forum.osdev.org/viewtopic.php?f=1&t=25795
+
+Triaging old bug tickets ... is there still something left to do here, or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+