Am 03.11.2017 um 15:18 hat Alberto Garcia geschrieben: > qcow2_do_open() is checking that header.refcount_table_clusters is not > too large, but it doesn't check that it's greater than zero. Apart > from the fact that an image like that is obviously corrupted, trying > to use it crashes QEMU since we end up with a null s->refcount_table > after qcow2_refcount_init(). > > These images can however be repaired, so allow opening them if the > BDRV_O_CHECK flag is set. > > Signed-off-by: Alberto Garcia <be...@igalia.com> > Reviewed-by: Max Reitz <mre...@redhat.com>
> --- a/tests/qemu-iotests/060 > +++ b/tests/qemu-iotests/060 > @@ -270,6 +270,13 @@ poke_file "$TEST_IMG" "$rb_offset" > "\x00\x00\x00\x00\x00\x00\x00\x00" > # write will try to allocate a compressed data cluster at offset 0. > $QEMU_IO -c "write -c 0k 64k" "$TEST_IMG" | _filter_qemu_io > > +echo > +echo "=== Testing zero refcount table size ===" > +echo > +_make_test_img 64M > +poke_file "$TEST_IMG" "56" "\x00\x00\x00\x00" > +$QEMU_IO -c "write 0 64k" "$TEST_IMG" 2>&1 | _filter_testdir | _filter_imgfmt In the commit message, you claim that the image can be repaired. Would it be worth actually testing the repair here? Kevin
