storage_file_probe: qcow2GetExtensions: Fix qcow2 header extension parsing

There are 3 bugs in the qcow2 header extension parser:

1) Header extension padding not taken into account

  Per qcow2 documentation (qemu.git/docs/interop/qcow2.txt, also now
  mirrored in the comment explaining the parser) each header extension
  entry is padded to a multiple of 8 bytes.

  Our parser didn't take the padding into account and advanced the
  current offset only by the 'length', which corresponds to the length
  of the data.

  This meant that in vast majority of cases only the first extension
  would be parsed correctly. For any other one we'd try to fetch the
  magic and length from wrong place.

  Luckily this wasn't a problem for most of the almost 15 years this bug
  existed as we only cared about the backing file format string header
  which was always stored first by qemu.

  It is now a problem in the very specific case when a qcow2 image has a
  'data-file' and also a backing store with format. In such case we'd
  parse the backing store format properly as it's the first header and
  'data-file' being the second would be skipped.

  The buffer bounds checks were correct so we didn't violate any memory
  boundaries.

2) Integer underflow in calculation of end of header extension block

  If the image doesn't have a backing image, the 'backing_file_offset'
  qcow2 header field is 0. We use that value as 'extensions_end' which
  is used in the while loop to parse the extension entries.

  The check was done as "offset < (extensions_end - 8)", thus it
  unreflows when there's no filename.

  The design of the loop prevented anything bad from happening though.

3) Off-by-one when determining end of header extension block

  The aforementioned end of extension check above also has an off-by-one
  error as it allowed another loop if more than 8 bytes were available.

  Now the termination entry has data length of 0 bytes so we'd not be
  able to properly process that one.

  This wasn't a problem either as for now there's just the terminator
  having 0 byte length.

This patch improves documentation by quoting the qcow2 interoperability
document and adjusts the loop condition and length handling to comply
with the specs.

Interestingly we also had a test case for this specific scenario but the
expected test output was wrong.

Fixes: a93402d48b2996e5300754d299ef0d3f646aa098
Resolves: https://issues.redhat.com/browse/RHEL-93775
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>

diff --git a/src/storage_file/storage_file_probe.c b/src/storage_file/storage_file_probe.c
index 04a2dcd9aa807365c4ea3220b6272adde270303f..f8857fa9347744db578892ba6e30fc31aadf263a 100644 (file)
--- a/src/storage_file/storage_file_probe.c
+++ b/src/storage_file/storage_file_probe.c
@@ -415,31 +415,21 @@ qcow2GetExtensions(const char *buf,
         extension_start = virReadBufInt32BE(buf + QCOW2v3_HDR_SIZE);
 
     /*
-     * Traditionally QCow2 files had a layout of
-     *
-     * [header]
-     * [backingStoreName]
-     *
-     * Although the backingStoreName typically followed
-     * the header immediately, this was not required by
-     * the format. By specifying a higher byte offset for
-     * the backing file offset in the header, it was
-     * possible to leave space between the header and
-     * start of backingStore.
-     *
-     * This hack is now used to store extensions to the
-     * qcow2 format:
+     * QCow2 header extensions are stored directly after the header before
+     * the (optional) backing store filename:
      *
      * [header]
      * [extensions]
      * [backingStoreName]
      *
-     * Thus the file region to search for extensions is
-     * between the end of the header (QCOW2_HDR_TOTAL_SIZE)
-     * and the start of the backingStoreName (offset)
+     * For qcow2(v2) the [header] portion has a fixed size (QCOW2_HDR_TOTAL_SIZE),
+     * whereas for qcow2v3 the size of the header itself is recorded inside
+     * the header (at offset QCOW2v3_HDR_SIZE).
      *
-     * for qcow2 v3 images, the length of the header
-     * is stored at QCOW2v3_HDR_SIZE
+     * Thus the file region to search for header extensions is
+     * between the end of the header and the start of the backingStoreName
+     * (QCOWX_HDR_BACKING_FILE_OFFSET) if a backing file is present (as
+     * otherwise the value at QCOWX_HDR_BACKING_FILE_OFFSET is 0)
      */
     extension_end = virReadBufInt64BE(buf + QCOWX_HDR_BACKING_FILE_OFFSET);
 
@@ -449,19 +439,28 @@ qcow2GetExtensions(const char *buf,
     if (extension_end > buf_size)
         return -1;
 
-    /*
-     * The extensions take format of
-     *
-     * int32: magic
-     * int32: length
-     * byte[length]: payload
-     *
-     * Unknown extensions can be ignored by skipping
-     * over "length" bytes in the data stream.
-     */
     offset = extension_start;
     while (offset < (buf_size-8) &&
-           offset < (extension_end-8)) {
+           (extension_end == 0 || offset <= (extension_end - 8))) {
+        /**
+         * Directly after the image header, optional sections called header
+         * extensions can
+         * be stored. Each extension has a structure like the following:
+         *
+         * Byte 0 -  3:   Header extension type:
+         *      0x00000000 - End of the header extension area
+         *      0xe2792aca - Backing file format name string
+         *      0x6803f857 - Feature name table
+         *      0x23852875 - Bitmaps extension
+         *      0x0537be77 - Full disk encryption header pointer
+         *      0x44415441 - External data file name string
+         *      other      - Unknown header extension, can be safely ignored
+         *
+         *      4 -  7:   Length of the header extension data
+         *      8 -  n:   Header extension data
+         *      n -  m:   Padding to round up the header extension size to the
+         *                next multiple of 8.
+         */
         unsigned int magic = virReadBufInt32BE(buf + offset);
         unsigned int len = virReadBufInt32BE(buf + offset + 4);
 
@@ -510,7 +509,8 @@ qcow2GetExtensions(const char *buf,
             return 0;
         }
 
-        offset += len;
+        /* take padding into account; see above */
+        offset += VIR_ROUND_UP(len, 8);
     }
 
     return 0;

diff --git a/tests/virstoragetestdata/out/qcow2datafile-qcow2_qcow2-datafile b/tests/virstoragetestdata/out/qcow2datafile-qcow2_qcow2-datafile
index c5a5d99e9e6ed8d73ca070c93f6a8b1609cff6cc..a200ba98fab74ff4c765047d9b1b906e2388dcc5 100644 (file)
--- a/tests/virstoragetestdata/out/qcow2datafile-qcow2_qcow2-datafile
+++ b/tests/virstoragetestdata/out/qcow2datafile-qcow2_qcow2-datafile
@@ -1,7 +1,7 @@
 path:ABS_SRCDIR/virstoragetestdata/images/qcow2datafile-datafile.qcow2
 backingStoreRaw: datafile.qcow2
 backingStoreRawFormat: qcow2(14)
-dataFileRaw: <null>
+dataFileRaw: raw
 capacity: 1024
 encryption: 0
 relPath:<null>
@@ -10,6 +10,14 @@ format:qcow2
 protocol:none
 hostname:<null>
 
+ dataFileStoreSource for 'ABS_SRCDIR/virstoragetestdata/images/qcow2datafile-datafile.qcow2':
+  path: ABS_SRCDIR/virstoragetestdata/images/raw
+  capacity: 0
+  encryption: 0
+  type:file
+  format:raw
+
+
 path:ABS_SRCDIR/virstoragetestdata/images/datafile.qcow2
 backingStoreRaw: <null>
 backingStoreRawFormat: none(0)