restructure results

1 files changed, 45 insertions, 0 deletions

diff --git a/results/classifier/zero-shot/118/device/786209 b/results/classifier/zero-shot/118/device/786209
new file mode 100644
index 00000000..337e5af1
--- /dev/null
+++ b/results/classifier/zero-shot/118/device/786209
@@ -0,0 +1,45 @@
+device: 0.810
+vnc: 0.649
+architecture: 0.634
+network: 0.605
+socket: 0.550
+kernel: 0.543
+graphic: 0.529
+semantic: 0.472
+arm: 0.472
+performance: 0.439
+risc-v: 0.429
+mistranslation: 0.429
+ppc: 0.397
+permissions: 0.389
+boot: 0.377
+i386: 0.358
+PID: 0.326
+peripherals: 0.326
+x86: 0.294
+files: 0.287
+register: 0.276
+VMM: 0.246
+TCG: 0.200
+debug: 0.190
+KVM: 0.162
+hypervisor: 0.134
+user-level: 0.101
+virtual: 0.091
+assembly: 0.084
+
+Information leak in IDE core
+
+When the DRQ_STAT bit is set, the IDE core permits both data reads and data writes, regardless of whether the current transfer was initiated as a read or write.
+
+Furthermore, the IO buffer is allocated via a qemu_memalign but not initialized or cleared at device creation.
+
+This potentially leaks uninitialized host memory into the guest, if, before doing anything else to an IDE device, the guest begins a write transaction (e.g. WIN_WRITE), but then *reads* from the IO port instead of writing to it. The IDE core will happily return the uninitialized contents of the buffer to the guest, potentially leaking offsets that could be used as part of an attack to get around ASLR.
+
+hi Nelson :
+    
+    what 's the flag 'DRQ_STAT' mean for   HD_STATUS ?
+
+Fixed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=40c4ed3f95f0b2ffa0848df0f
+