From: Peter Krempa <pkre...@redhat.com> 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 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 lenght. This patch improves documentation by quoting the qcow2 interoperability document and adjusts the loop condition and lenght 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 <pkre...@redhat.com> --- src/storage_file/storage_file_probe.c | 62 +++++++++---------- .../out/qcow2datafile-qcow2_qcow2-datafile | 10 ++- 2 files changed, 40 insertions(+), 32 deletions(-) diff --git a/src/storage_file/storage_file_probe.c b/src/storage_file/storage_file_probe.c index 04a2dcd9aa..f8857fa934 100644 --- 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 c5a5d99e9e..a200ba98fa 100644 --- 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) -- 2.49.0
