On Tue, Apr 03, 2018 at 13:01:48 +0200, Peter Krempa wrote:
On Tue, Apr 03, 2018 at 11:56:33 +0100, Daniel Berrange wrote:
> On Fri, Mar 30, 2018 at 12:59:07PM +0200, Peter Krempa wrote:
> > Coverity was not wrong about the usage of 'a'/'A' modifiers
for
> > virJSONValueObjectAddVArgs as noted in [1]. Fix the possible
> > leak/double-free, and add test to make sure it works as expected.
>
> Do you have any idea how to trigger the double-free scenario ? In particular
> is it something that a broken / malicious QEMU monitor / guest agent can
> cause us todo. If so we'll need to request a CVE assignment for this flaw.
It can be triggered when we are formatting the virJSONValue using
callers of virJSONValueObjectAddVArgs, so it would require malformed
parameters to a libvirt API and I did not inspec the possibility of
that.
You can see the paths which potentially could hit the double-free in
this patch, since it's modifying all the cases.
All paths where we format anything after an 'a' or 'A' valuea which can
fail after the 'a' or 'A' was successful and then the original value is
freed.
So the calls which match the above condition are from:
qemuBlockStorageSourceGetNBDProps,
qemuBlockStorageSourceGetRBDProps,
qemuBlockStorageSourceGetSshProps,
qemuMonitorJSONSendKey
All of the above format only optional strings ('S') or integers after
the 'a'/'A' argument, so the double free scenario would happen only on a
out-of-memory condition.
I doubt that it's CVE-material
It's not.