qcow2: Assert that refcount block offsets fit in the refcount table
PATCH 1/1 qcow2: Assert that refcount block offsets fit in the refcount table
Refcount table entries have a field to store the offset of the refcount block. The rest of the bits of the entry are currently reserved.
The offset is always taken from the entry using REFT_OFFSET_MASK to ensure that we only use the bits that belong to that field.
While that mask is used every time we read from the refcount table, it is never used when we write to it. Due to the other constraints of the qcow2 format QEMU can never produce refcount block offsets that don't fit in that field so any such offset when allocating a refcount block would indicate a bug in QEMU.
--- block/qcow2-refcount.c | 3 +++ 1 file changed, 3 insertions(+)
block/qcow2-refcount.c +3 -0
@@ -367,6 +367,9 @@ static int alloc_refcount_block(BlockDriverState *bs,return new_block; } +/* The offset must fit in the offset field of the refcount table entry */ +assert ((new_block &REFT_OFFSET_MASK ) == 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 "
Signature · 1 line
2.11.0
Quoted 7 lines · Alberto Garcia
Refcount table entries have a field to store the offset of the refcount block. The rest of the bits of the entry are currently reserved.
The offset is always taken from the entry using
REFT_OFFSET_MASKto ensure that we only use the bits that belong to that field.
Quoted 9 lines
While that mask is used every time we read from the refcount table, it is never used when we write to it. Due to the other constraints of the qcow2 format QEMU can never produce refcount block offsets that don't fit in that field so any such offset when allocating a refcount block would indicate a bug in QEMU.
--- block/qcow2-refcount.c | 3 +++ 1 file changed, 3 insertions(+)
Signature · 3 lines
Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Quoted 17 lines · Eric Blake
Quoted 7 lines
Refcount table entries have a field to store the offset of the refcount block. The rest of the bits of the entry are currently reserved.
The offset is always taken from the entry using
REFT_OFFSET_MASKto ensure that we only use the bits that belong to that field.Quoted 9 lines
While that mask is used every time we read from the refcount table, it is never used when we write to it. Due to the other constraints of the qcow2 format QEMU can never produce refcount block offsets that don't fit in that field so any such offset when allocating a refcount block would indicate a bug in QEMU.
--- block/qcow2-refcount.c | 3 +++ 1 file changed, 3 insertions(+)
Quoted 1 line
Reviewed-by Eric Blake <[email protected]>
Yes, for 3.1, shall I resend it with the updated subject message?
Berto
Am 14.11.2018 um 08:10 hat Alberto Garcia geschrieben:
Quoted 6 lines · Eric Blake
Quoted 5 lines
Quoted 5 lines
Refcount table entries have a field to store the offset of the refcount block. The rest of the bits of the entry are currently reserved.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
The offset is always taken from the entry using
REFT_OFFSET_MASKto ensure that we only use the bits that belong to that field.While that mask is used every time we read from the refcount table, it is never used when we write to it. Due to the other constraints of the qcow2 format QEMU can never produce refcount block offsets that don't fit in that field so any such offset when allocating a refcount block would indicate a bug in QEMU.
Missing S-o-b.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
block/qcow2-refcount.c | 3 +++ 1 file changed, 3 insertions(+)Reviewed-by Eric Blake <[email protected]>Yes, for 3.1, shall I resend it with the updated subject message?
Honestly, I don't see why an additional assertion should qualify as a fix? If it changes the behaviour, it's a bug.
You wouldn't have to resend for the updated subject message, but you do for the missing S-o-b.
Kevin
Quoted 6 lines · Kevin Wolf
Quoted 3 lines
Quoted 1 line
Reviewed-by Eric Blake <[email protected]>Yes, for 3.1, shall I resend it with the updated subject message?
Honestly, I don't see why an additional assertion should qualify as a fix? If it changes the behaviour, it's a bug.
We can leave it for after 3.1 if you think it's more appropriate. I'll resend it with the S-o-b anyway.
Berto