Because we allow a QEMU_JOB_DESTROY to occur while we're starting
up and we drop the @vm lock prior to qemuMonitorOpen, it's possible
that a domain destroy operation "wins" the race, calls qemuProcessStop
which will free and reinitialize priv->monConfig. Depending on the
exact timing either qemuMonitorOpen will be passed a NULL @config
variable or it will be using free'd (and possibly reclaimed) memory
as the @config parameter - neither of which is good.
Resolve this by localizing the @monConfig, taking an extra reference,
and then once we get the @vm lock again removing our reference since
we are done with it.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
qemuDomainObjPrivatePtr priv = vm->privateData;
qemuMonitorPtr mon = NULL;
unsigned long long timeout = 0;
+ virDomainChrSourceDefPtr monConfig;
if (qemuSecuritySetDaemonSocketLabel(driver->securityManager, vm->def) < 0) {
VIR_ERROR(_("Failed to set security context for monitor for %s"),
virObjectRef(vm);
ignore_value(virTimeMillisNow(&priv->monStart));
+ monConfig = priv->monConfig;
+ virObjectRef(monConfig);
virObjectUnlock(vm);
mon = qemuMonitorOpen(vm,
- priv->monConfig,
+ monConfig,
priv->monJSON,
timeout,
&monitorCallbacks,
}
virObjectLock(vm);
+ virObjectUnref(monConfig);
virObjectUnref(vm);
priv->monStart = 0;