[Qemu-devel] qemu-iotest 059 vmdk failure

[John Snow]

The last sub-test in 059, which uses an AFL fuzzer image to test for how
a large L1 table of a specific size is handled has a slight regression.

Previously, QEMU expects -EFBIG to come out the vmdk_open call. Now, we
get -EINVAL. Not too ominous.

Now, QEMU actually allocates the L1 table (1.6GB) and gets a little
further, only to eventually trip up here:

#0  vmdk_read_cid (bs=0x555555d4c5a0, parent=0, pcid=0x555555d5786c) at
/home/bos/jhuston/src/qemu/block/vmdk.c:272
#1  0x00005555555947cb in vmdk_open (bs=0x555555d4c5a0,
options=0x555555d509b0, flags=65536, errp=0x7fffffffd950)
    at /home/bos/jhuston/src/qemu/block/vmdk.c:989

where p_name is NULL, so we return -EINVAL back up the stack. We get all
the way through vmdk_open_sparse --> vmdk_open_vmdk4 before we
eventually catch an error in the header and return a fairly nondescript
EINVAL which doesn't tell the end user much.

We don't error out earlier because the vmdk_add_extent function checks
to see if we are exceeding 512*1024*1024 ... entries, which means that
later when we get to vmdk_init_tables, we do multiply this number by
four again, so our actual maximum L1 table size in terms of bytes is
2GiB, not 512MiB.

(Maybe you knew that, I didn't, enjoy useless facts. The comment in code
seemed to suggest the size was a literal size in bytes, but it's treated
more as the number of L1 entries, which is different.)

Anyway, this still seems slightly silly that we don't catch obviously
bogus images a little sooner, so I wanna rewind and see why we don't get
-EFBIG anymore.

The output changes as of 9877860e which adds the p_name check, so we
appear to actually be failing even earlier, just not before we
apparently load up a 2GB L1 table from a file that clocks in at less
than 1KB.

(Wait, why does that work? Am I tracing this wrong? -EOUTTATIME)

Anyway, we can fix this by amending the reference test output, or we
might want to shore up the vmdk input validation a bit.

Not a regression, and the test was broken in v2.10 anyway, so not
critical to fix during rc phase, I think.

Anyway, I need to go prepare some food for Thanksgiving, so I won't come
back to this one for a few days. If it's not important to anyone else,
I'll get back around to it eventually.

--js