blob: c932d48e460745a27169f460fda14a465631c4e5 (
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
55
56
57
58
59
60
61
62
63
64
65
|
graphic: 0.816
device: 0.706
instruction: 0.678
KVM: 0.613
socket: 0.600
network: 0.593
vnc: 0.575
semantic: 0.537
boot: 0.474
assembly: 0.467
other: 0.420
mistranslation: 0.414
QEMU: block/vvfat driver issues
Nathan Huckleberry <email address hidden> has reported following issues in the block/vvfat driver for the virtual VFAT file system image, used to share a host system directory with a guest VM.
Please note:
-> https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images
Virtual VFAT read/write support is available only for (beta) testing purposes.
Following issues are reproducible with:
host)$ ./bin/qemu-system-x86_64 -nographic -enable-kvm \
-drive file=fat:rw:/tmp/var/run/,index=2 -m 2048 /var/lib/libvirt/images/f27vm.qcow2
guest)# mount -t vfat /dev/sdb1 /mnt/
The attached reproducers (run inside a guest) include:
1. dir.sh: - directory traversal on the host
- It creates a file under /mnt/yyyy
- Then edits the VFAT directory entry to make it -> /mnt/../y
- The handle_renames_and_mkdirs() routine does not check this new file name
and creates a file outside of the shared directory on the host
2. dos.sh: hits an assertion failure in vvfat driver
- Creates a deep directory tree like - /mnt/0/1/2/3/4/5/6/../29/30/
- While updating vvfat commits, driver hits an assertion in
handle_renames_and_mkdirs
...
} else if (commit->action == ACTION_MKDIR) {
...
assert(j < s->mapping.next); <== it fails
3. read.sh: reads past vvfat directory entries
- Creates a file with: echo "x" > /mnt/a
- Reads past VVFAT directory entry structure with
# head -c 1000000 $MNTDEV | xxd | grep x -A 512
- It may disclose some heap addresses.
4. write.sh: heap buffer overflow
- Creates large number of files as /mnt/file[1..35]
- while syncing directory tree with the host, driver hits an overflow
while doing memmove(3) in array_roll() routine
This ticket has been transferred to QEMU's new bug tracker here:
https://gitlab.com/qemu-project/qemu/-/issues/272
... thus closing the issue on Launchpad now.
|