On Tue, Aug 07, 2018 at 09:05:09AM +0200, Peter Krempa wrote: > On Tue, Aug 07, 2018 at 09:42:05 +0800, Han Han wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1612009 > > > > Check sev capability pointer in function qemuGetSEVInfoToParams to avoid > > null pointer dereferences. > > > > Signed-off-by: Han Han <hhan@xxxxxxxxxx> > > --- > > src/qemu/qemu_driver.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c > > index fb0d4a8c7a..3daaef586f 100644 > > --- a/src/qemu/qemu_driver.c > > +++ b/src/qemu/qemu_driver.c > > @@ -21452,6 +21452,12 @@ qemuGetSEVInfoToParams(virQEMUCapsPtr qemuCaps, > > > > virCheckFlags(VIR_TYPED_PARAM_STRING_OKAY, -1); > > > > + if (!sev) { > > + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", > > + _("SEV is not supported in this guest")); > > + return -1; > > + } > > I presume the crash happens after restart of libvirtd. The real bug is > that qemuCaps don't serialize the sev data into the status XML thus the > pointer will be cleared and NULL after libvirtd restart. > > The error message reported here is then wrong since the guest/host > support SEV but the data is not available. > > The crash would not happen otherwise as the function is guarded by > checking QEMU_CAPS_SEV_GUEST. Exactly, I'm currently working on it, Peter is right, this is not the right fix. Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
