blob: 337e5af1213d13a4d22a00f318311b8062261988 (
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
|
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
|