add 18th iteration of classifier

1 files changed, 49 insertions, 0 deletions

diff --git a/results/classifier/118/graphic/1892761 b/results/classifier/118/graphic/1892761
new file mode 100644
index 000000000..171e25952
--- /dev/null
+++ b/results/classifier/118/graphic/1892761
@@ -0,0 +1,49 @@
+graphic: 0.903
+device: 0.862
+performance: 0.683
+socket: 0.638
+architecture: 0.608
+network: 0.597
+arm: 0.570
+risc-v: 0.519
+vnc: 0.475
+kernel: 0.472
+user-level: 0.471
+semantic: 0.469
+i386: 0.442
+VMM: 0.403
+boot: 0.399
+PID: 0.390
+register: 0.383
+KVM: 0.368
+x86: 0.365
+debug: 0.355
+peripherals: 0.334
+assembly: 0.319
+ppc: 0.318
+TCG: 0.297
+hypervisor: 0.255
+files: 0.251
+virtual: 0.249
+mistranslation: 0.230
+permissions: 0.112
+
+Heap-use-after-free through double-fetch in ehci
+
+Hello,
+I don't have a qtest reproducer for this crash because it involves a DMA double-fetch, and I don't think we can reproduce those with qtest.
+
+Instead, I attached the pseudo-qtest trace produced by the fuzzer, along with some trace events.
+The lines annotated with [DMA] are write commands that were triggered by a callback from a DMA read by the device. The lines annotated with [DOUBLE-FETCH] are DMA accesses that hit the same address more than once (possible double-fetches).
+
+I am still thinking of nicer ways of presenting this trace and providing a reproducer.
+-Alex
+
+
+
+Hi Alexander! Have you ever been able to create a reproducer for this problem?
+
+No. If we figure out some way to consistently reproduce double-fetches in a non-fuzzer build, I'll report the issue again, but this can probably be closed
+
+Ok, let's close this one since it was not reproducible. If you find a reproducer, please open a new ticket in the gitlab tracker instead.
+