]> xenbits.xensource.com Git - qemu-upstream-4.2-testing.git/commitdiff
qcow1: Validate L2 table size (CVE-2014-0222)
authorKevin Wolf <kwolf@redhat.com>
Thu, 5 Mar 2015 11:01:07 +0000 (11:01 +0000)
committerStefano Stabellini <stefano.stabellini@eu.citrix.com>
Thu, 5 Mar 2015 18:16:00 +0000 (18:16 +0000)
Too large L2 table sizes cause unbounded allocations. Images actually
created by qemu-img only have 512 byte or 4k L2 tables.

To keep things consistent with cluster sizes, allow ranges between 512
bytes and 64k (in fact, down to 1 entry = 8 bytes is technically
working, but L2 table sizes smaller than a cluster don't make a lot of
sense).

This also means that the number of bytes on the virtual disk that are
described by the same L2 table is limited to at most 8k * 64k or 2^29,
preventively avoiding any integer overflows.

Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
block/qcow.c

index 4814ed0ced7d7d347719a0969931ef51a07a6a50..c0ed624327531da8fcea76586144c689f7ae6d3f 100644 (file)
@@ -113,6 +113,13 @@ static int qcow_open(BlockDriverState *bs, int flags)
         goto fail;
     if (header.size <= 1 || header.cluster_bits < 9)
         goto fail;
+
+    /* l2_bits specifies number of entries; storing a uint64_t in each entry,
+     * so bytes = num_entries << 3. */
+    if (header.l2_bits < 9 - 3 || header.l2_bits > 16 - 3) {
+        goto fail;
+    }
+
     if (header.crypt_method > QCOW_CRYPT_AES)
         goto fail;
     s->crypt_method_header = header.crypt_method;