qemu: Obtain reference on monConfig

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>
This commit is contained in:
John Ferlan 2018-04-06 12:14:44 -04:00
parent 2ada9ef146
commit a5a777a8ba

View File

@ -1776,6 +1776,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, virDomainObjPtr vm, int asyncJob,
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"),
@ -1794,10 +1795,12 @@ qemuConnectMonitor(virQEMUDriverPtr driver, virDomainObjPtr vm, int asyncJob,
virObjectRef(vm);
ignore_value(virTimeMillisNow(&priv->monStart));
monConfig = priv->monConfig;
virObjectRef(monConfig);
virObjectUnlock(vm);
mon = qemuMonitorOpen(vm,
priv->monConfig,
monConfig,
priv->monJSON,
timeout,
&monitorCallbacks,
@ -1812,6 +1815,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, virDomainObjPtr vm, int asyncJob,
}
virObjectLock(vm);
virObjectUnref(monConfig);
virObjectUnref(vm);
priv->monStart = 0;