Comment 157 for bug 2059809

Revision history for this message
Felix Huettner (felix.huettner) wrote : Re: Arbitrary file access through QCOW2 external data file (CVE-2024-32498)

The previously described before works as follows even with the above patch:

1. Create some normal server and login to it
2. Create an empty volume (on the backend the volume must be created as raw and not as qcow2)
3. Attach the volume to the server
4. Write a thin provisioned qcow2 file with a large virtual size to the volume from the VM (so that qemu-img info /dev/vdb works). The virtual size can be significantly larger than the current size of the volume
5. Create a snapshot from the volume
6. Create a new volume from the snapshot
7. Attach the new volume to the same VM

Observe how the volume in the vm shows the new virtual size and you can use this virtual size completely.
However cinder shows the size of the original volume (as the size is taken from the snapshot value).

I don't think we can fix this nicely, as long as we do not persistently store the disk_format through any kind of operation (snapshots, backups, etc.) and never rely on format detection.
However i attached a fix based on comparing the size of the disks. I am however not sure of it's side effects (also probably some tests fail).

Maybe it would also be better to split this out to another private issue, to not make this even more complex?