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: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

src/qemu/qemu_process.c

@@ -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;