On Tue, Apr 03, 2018 at 01:07:29PM +0200, Peter Krempa wrote:
> 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.
Great, thanks for checking
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
