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.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
