files: 0.117
device: 0.111
other: 0.097
semantic: 0.083
socket: 0.074
permissions: 0.074
PID: 0.072
network: 0.064
performance: 0.062
graphic: 0.061
KVM: 0.055
vnc: 0.053
debug: 0.042
boot: 0.035
debug: 0.682
PID: 0.055
other: 0.038
files: 0.038
device: 0.031
performance: 0.027
semantic: 0.026
network: 0.021
KVM: 0.020
graphic: 0.016
permissions: 0.015
boot: 0.013
socket: 0.010
vnc: 0.008

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.