blob: 27cfffa6bdf75c411de71ae0392b6cab93d035b7 (
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
50
51
52
53
54
|
graphic: 0.900
performance: 0.896
semantic: 0.580
device: 0.576
network: 0.528
ppc: 0.522
vnc: 0.490
mistranslation: 0.468
i386: 0.461
architecture: 0.446
socket: 0.438
risc-v: 0.438
user-level: 0.423
boot: 0.417
VMM: 0.414
PID: 0.408
files: 0.381
TCG: 0.379
x86: 0.366
kernel: 0.345
register: 0.305
arm: 0.300
virtual: 0.297
KVM: 0.291
peripherals: 0.279
permissions: 0.278
hypervisor: 0.264
debug: 0.247
assembly: 0.110
qemu-io: the 'map' command hangs on the fuzzed image
Sequence:
1. Unpack the attached archive, make a copy of test.img
2. Put copy.img and backing_img.vdi in the same directory
3. Execute
qemu-io copy.img -c map
Result: qemu-io processes part of the image and then hangs loading 100% of CPU time.
qemu.git HEAD 2d591ce2aeebf
Hi,
well, the issue for this specific image is fixed because it is detected to be corrupt before the mapping can reach the point in question (unaligned L2 table entry). However, commit 4b25bbc4c22cf39350b75bd250d568a4d975f7c5 should have fixed the problem this bug report is really about. Thus, should be fixed.
Thanks for reporting,
Max
|
