| Message ID | ae3d77f312fc0c5e0ac2bbd71676c0112eebe2e5.1509718618.git.berto@igalia.com |
|---|---|
| State | New |
| Headers | show |
| Series | Misc qcow2 corruption checks | expand |
On Fri, Nov 03, 2017 at 04:18:56PM +0200, Alberto Garcia wrote: > The crypto header is initialized only when QEMU is creating a new > image, so there's no chance of this happening on a corrupted image. > > If QEMU is really trying to allocate the header overlapping other > existing metadata sections then this is a serious bug in QEMU itself > so let's add an assertion. > > Signed-off-by: Alberto Garcia <berto@igalia.com> > --- > block/qcow2.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Regards, Daniel
diff --git a/block/qcow2.c b/block/qcow2.c index defc1fe49f..b3d66a0e88 100644 --- a/block/qcow2.c +++ b/block/qcow2.c @@ -126,6 +126,7 @@ static ssize_t qcow2_crypto_hdr_init_func(QCryptoBlock *block, size_t headerlen, /* Zero fill remaining space in cluster so it has predictable * content in case of future spec changes */ clusterlen = size_to_clusters(s, headerlen) * s->cluster_size; + assert(qcow2_pre_write_overlap_check(bs, 0, ret, clusterlen) == 0); ret = bdrv_pwrite_zeroes(bs->file, ret + headerlen, clusterlen - headerlen, 0);
The crypto header is initialized only when QEMU is creating a new image, so there's no chance of this happening on a corrupted image. If QEMU is really trying to allocate the header overlapping other existing metadata sections then this is a serious bug in QEMU itself so let's add an assertion. Signed-off-by: Alberto Garcia <berto@igalia.com> --- block/qcow2.c | 1 + 1 file changed, 1 insertion(+)