[libvirt] [PATCH 0/9] json: Fix leak/double-free, clean up code and privatize virJSONValue

[Peter Krempa]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180403/4d4fa6f1/attachment-0001.sig>