1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/111/review/1892761 b/results/classifier/111/review/1892761
new file mode 100644
index 00000000..bb409356
--- /dev/null
+++ b/results/classifier/111/review/1892761
@@ -0,0 +1,48 @@
+other: 0.185
+semantic: 0.139
+device: 0.137
+graphic: 0.095
+performance: 0.078
+debug: 0.060
+network: 0.052
+PID: 0.051
+vnc: 0.044
+files: 0.038
+socket: 0.037
+permissions: 0.033
+boot: 0.028
+KVM: 0.023
+debug: 0.286
+performance: 0.212
+other: 0.134
+files: 0.077
+device: 0.068
+PID: 0.046
+semantic: 0.039
+KVM: 0.034
+network: 0.023
+socket: 0.020
+graphic: 0.017
+boot: 0.017
+vnc: 0.014
+permissions: 0.013
+
+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.
+