On Thu 02 Nov 2017 06:28:18 PM CET, Max Reitz wrote:
>> diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
>> index aa3fd6cf17..9059996c4b 100644
>> --- a/block/qcow2-refcount.c
>> +++ b/block/qcow2-refcount.c
>> @@ -367,6 +367,13 @@ static int alloc_refcount_block(BlockDriverState *bs,
>> return new_block;
>> }
>>
>> + /* If we're allocating the block at offset 0 then something is wrong */
>> + if (new_block == 0) {
>> + qcow2_signal_corruption(bs, true, -1, -1, "Preventing invalid "
>
> Technically, the offset is 0 and the size is s->cluster_size, but I
> won't insist.
I actually checked the rest of qcow2_signal_corruption() cases in that
file and almost all use -1, -1.
I understand that the problem is not in [0, s->cluster_size] but in the
refcount table/block (the refcount data is wrong). The documentation of
BLOCK_IMAGE_CORRUPTED says:
# @offset: if the corruption resulted from an image access, this is the
# host's access offset into the image
# @size: if the corruption resulted from an image access, this is the
# access size
But that's not quite the case here, or is it?
Berto
