Comment 62 for bug 2059809

"IIUC, the child files don't show up in either the backing_file or data_file fields, rather, we need to pick them up out of this embedded QMP block devices definition thingy."

I don't know what this means outside of the guest agent and/or a running qemu. I'm still struggling to understand how any of this has anything to do with a qcow2 file's specification. AFAIK, the use of quorum (or the storage driver at all) only comes into the picture when you're running qemu and setting up the *actual* storage. I must be missing how this gets encoded into an actual top-level qcow2 file. Can someone point to docs on how that happens and/or just show qemu-img commands that results in this multi-hierarchical setup that references a quorum setup?

"So I don't think the current patches protect against the exploit outlined in comments #44 and #50. But maybe your point is that the current patches are good for the external data_file exploit, and this block device thing needs to be a separate CVE?"

I don't understand that what is described in #50 is exploitable. It says very clearly "If a data file is used" and if we're disallowing that in the top-level qcow2 file we pulled from glance and hand to the qemu we run then I'm not sure how you would end up with a running qemu with a quorum-based storage arrangement.

Sorry if I'm being dense and/or distracted with PTG going on this week, but everything related to the block device stuff seems to be predicated on "you could do this with qemu and have something bad happen" but I don't see the _actual_ exploit path. Perhaps we need a higher-bandwidth discussion if I'm just missing something major here.