On Fri, May 23, 2025 at 01:20:32PM -0500, Eric Blake wrote: > Ever since CVE-2024-4467 (see commit 7ead9469 in qemu v9.1.0), we have > intentionally treated command-line arguments as local files, and not > protocol specifications (you have to specify backing files with > full-blown QMP if it is intentional to access something more > complicated). However, that patch forgot about qcow2 data-file, which > is another place where we really should not be hard-coding protocol > names in the qcow2 metadata. > > Fix this by changing the decision point on whether to allow protocols > to each driver, rather than hard-coded to true in the generic code; > qcow2 data_file is the only place where we change the former default > of true.
I should probably add an example to the commit message: Pre-patch: $ qemu-img create -f qcow2 -o data_file=rbd:virtual-disk-ceph-pool/datastore... datastore_rbd.qcow2 500M tries to access the remote disk using rbd; but the "External data file name" extension header in qcow2 stores an empty string; so the qcow2 file can't be reopened without QMP anyway. Post-patch, the creation attempt fails with: $ qemu-img create -f qcow2 -o data_file=rbd:virtual-disk-ceph-pool/datastore datastore_rbd.qcow2 500M Formatting 'datastore_rbd.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=524288000 data_file=rbd:virtual-disk-ceph-pool/datastore lazy_refcounts=off refcount_bits=16 qemu-img: datastore_rbd.qcow2: Could not create 'rbd:virtual-disk-ceph-pool/datastore': No such file or directory and no qcow2 file is created. It is still possible to use QMP to open a qcow2 wrapper with rbd as the backing file. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
