x86: 0.888
virtual: 0.837
graphic: 0.816
performance: 0.767
files: 0.745
peripherals: 0.730
device: 0.706
architecture: 0.700
permissions: 0.674
KVM: 0.613
PID: 0.605
socket: 0.600
network: 0.593
kernel: 0.576
vnc: 0.575
register: 0.566
ppc: 0.565
hypervisor: 0.561
semantic: 0.537
VMM: 0.526
arm: 0.482
boot: 0.474
user-level: 0.469
assembly: 0.467
i386: 0.463
mistranslation: 0.414
risc-v: 0.391
debug: 0.372
TCG: 0.345

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.