blob: 171e25952113dee201bc19a707cfcc7906ff5437 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
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.
|
