diff -Nru libvirt-6.0.0/debian/changelog libvirt-6.0.0/debian/changelog --- libvirt-6.0.0/debian/changelog 2024-04-12 17:50:27.000000000 +0000 +++ libvirt-6.0.0/debian/changelog 2024-04-16 17:20:13.000000000 +0000 @@ -1,3 +1,45 @@ +libvirt (6.0.0-0ubuntu8.20) focal; urgency=medium + + * d/p/u/lp2059272-2-qemu-Wait-qemuProcessReconnect-threads-in-cleanup.patch: + Remove patch. It is not possible to wait for qemuProcessReconnect() + in cleanup: it talks to QEMU monitor, which blocks on replies from + event loop, but it's already stopped at cleanup, delaying shutdown. + + * d/p/u/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch: + Instead of waiting at cleanup for threads which might be blocked + thus would _not even reach_ the function that causes the problem, + just skip that function if it is _actually reached_ while daemon + shutdown is in progress. That is in the init path and would just + run again anyway the next time libvirtd is started (LP: #2059272) + + * NOTE: This package contains the changes from 6.0.0-0ubuntu8.18 and + 6.0.0-0ubuntu8.17 in focal-proposed (with symbolic changelog entry) + superseded by 6.0.0-0ubuntu8.19 in focal-security. + + -- Mauricio Faria de Oliveira Tue, 16 Apr 2024 14:20:13 -0300 + +libvirt (6.0.0-0ubuntu8.20~ubuntu8.18) focal; urgency=medium + + * d/p/u/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch: + On QEMU driver cleanup, release (stop) the worker thread pool _first_, + before other data used by possibly running worker threads (LP: #2059272) + + * d/p/u/lp2059272-2-qemu-Wait-qemuProcessReconnect-threads-in-cleanup.patch: + On QEMU driver cleanup, also wait for qemuProcessReconnect() threads, + as they are independent of the worker thread pool. (LP: #2059272) + Focal needs this as it has no .stateShutdownWait() callback yet. + (The wait timeout is set in LIBVIRT_QEMU_STATE_CLEANUP_WAIT_TIMEOUT: + -1 = wait indefinitely; 0 = do not wait; N = wait up to N seconds.) + + -- Mauricio Faria de Oliveira Sat, 30 Mar 2024 17:05:56 -0300 + +libvirt (6.0.0-0ubuntu8.20~ubuntu8.17) focal; urgency=medium + + * d/p/u/lp-1989078-*.patch: allow arm64 to lock its OVMF/AAVMF resources + (LP: #1989078) + + -- Christian Ehrhardt Mon, 09 Jan 2023 08:48:16 +0100 + libvirt (6.0.0-0ubuntu8.19) focal-security; urgency=medium * SECURITY UPDATE: off-by-one in udevListInterfacesByStatus() diff -Nru libvirt-6.0.0/debian/patches/series libvirt-6.0.0/debian/patches/series --- libvirt-6.0.0/debian/patches/series 2024-04-12 17:49:50.000000000 +0000 +++ libvirt-6.0.0/debian/patches/series 2024-04-16 17:03:03.000000000 +0000 @@ -189,3 +189,7 @@ CVE-2024-1441.patch CVE-2024-2494.patch CVE-2024-2496.patch +ubuntu/lp-1989078-apparmor-Fix-QEMU-access-for-UEFI-variable-files.patch +ubuntu/lp-1989078-apparmor-Allow-locking-AAVMF-firmware.patch +ubuntu/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch +ubuntu/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch diff -Nru libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Allow-locking-AAVMF-firmware.patch libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Allow-locking-AAVMF-firmware.patch --- libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Allow-locking-AAVMF-firmware.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Allow-locking-AAVMF-firmware.patch 2024-04-16 17:02:55.000000000 +0000 @@ -0,0 +1,32 @@ +From 2b98d5d91d95087d8a96d6450fa96414ed05ba5c Mon Sep 17 00:00:00 2001 +From: Andrea Bolognani +Date: Mon, 23 May 2022 10:31:02 +0200 +Subject: [PATCH] apparmor: Allow locking AAVMF firmware + +We already allow this for OVMF. + +Closes: https://gitlab.com/libvirt/libvirt/-/issues/312 +Signed-off-by: Andrea Bolognani +Reviewed-by: Martin Kletzander + +X-Backport-Note: 07af71ad has not landed yet and since it sorted all entries + there is some non-functional noise +Origin: backport, https://gitlab.com/libvirt/libvirt/-/commit/2b98d5d91 +Bug-Ubuntu: https://bugs.launchpad.net/bugs/1989078 +Last-Update: 2023-01-09 + +--- + src/security/apparmor/libvirt-qemu | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/src/security/apparmor/libvirt-qemu ++++ b/src/security/apparmor/libvirt-qemu +@@ -91,7 +91,7 @@ + /usr/share/misc/sgabios.bin r, + /usr/share/ovmf/** rk, + /usr/share/OVMF/** rk, +- /usr/share/AAVMF/** r, ++ /usr/share/AAVMF/** rk, + /usr/share/qemu-efi/** r, + /usr/share/slof/** r, + diff -Nru libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Fix-QEMU-access-for-UEFI-variable-files.patch libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Fix-QEMU-access-for-UEFI-variable-files.patch --- libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Fix-QEMU-access-for-UEFI-variable-files.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-6.0.0/debian/patches/ubuntu/lp-1989078-apparmor-Fix-QEMU-access-for-UEFI-variable-files.patch 2024-04-16 17:02:55.000000000 +0000 @@ -0,0 +1,48 @@ +From 7aec69b7fb9d0cfe8b7203473764c205b28d2905 Mon Sep 17 00:00:00 2001 +From: Martin Pitt +Date: Fri, 25 Feb 2022 14:07:30 +0000 +Subject: [PATCH] apparmor: Fix QEMU access for UEFI variable files + +QEMU needs to read, write, and lock the NVRAM *.fd files with UEFI +firmware. + +Fixes: https://bugs.debian.org/1006324 +Fixes: https://launchpad.net/bugs/1962035 + +Signed-off-by: Martin Pitt +Reviewed-by: Christian Ehrhardt + +X-Backport-Note: 07af71ad has not landed yet and since it sorted all entries + there is some non-functional noise +Origin: backport, https://gitlab.com/libvirt/libvirt/-/commit/7aec69b7f +Bug-Ubuntu: https://bugs.launchpad.net/bugs/1989078 +Bug-Debian: https://bugs.debian.org/1006324 +Last-Update: 2023-01-09 + +--- + src/security/apparmor/libvirt-qemu | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/src/security/apparmor/libvirt-qemu ++++ b/src/security/apparmor/libvirt-qemu +@@ -89,8 +89,8 @@ + /usr/share/vgabios/** r, + /usr/share/seabios/** r, + /usr/share/misc/sgabios.bin r, +- /usr/share/ovmf/** r, +- /usr/share/OVMF/** r, ++ /usr/share/ovmf/** rk, ++ /usr/share/OVMF/** rk, + /usr/share/AAVMF/** r, + /usr/share/qemu-efi/** r, + /usr/share/slof/** r, +@@ -264,5 +264,9 @@ + / r, # harmless on any lsb compliant system + /sys/bus/nd/devices/{,**/} r, + ++ # required for QEMU accessing UEFI nvram variables ++ owner /var/lib/libvirt/qemu/nvram/*_VARS.fd rwk, ++ owner /var/lib/libvirt/qemu/nvram/*_VARS.ms.fd rwk, ++ + # Site-specific additions and overrides. See local/README for details. + #include diff -Nru libvirt-6.0.0/debian/patches/ubuntu/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch libvirt-6.0.0/debian/patches/ubuntu/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch --- libvirt-6.0.0/debian/patches/ubuntu/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-6.0.0/debian/patches/ubuntu/lp2059272-1-qemu-Fix-potential-crash-during-driver-cleanup.patch 2024-04-16 17:02:59.000000000 +0000 @@ -0,0 +1,60 @@ +Bug-Ubuntu: http://bugs.launchpad.net/bugs/2059272 +Origin: backport, https://gitlab.com/libvirt/libvirt/-/commit/152770333449cd3b78b4f5a9f1148fc1f482d842 +[mfo: backport: hunk 1: refresh one context line: closeCallbacks] + +From 152770333449cd3b78b4f5a9f1148fc1f482d842 Mon Sep 17 00:00:00 2001 +From: Jim Fehlig +Date: Tue, 11 Apr 2023 09:15:43 -0600 +Subject: [PATCH] qemu: Fix potential crash during driver cleanup + +During qemu driver shutdown, objects are freed in qemuStateCleanup that +could still be used by active worker threads, resulting in crashes. E.g. +a worker thread could be processing a monitor EOF event after the +security manager is already disposed + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00007fd9a9a1e1fe in virSecurityManagerMoveImageMetadata (mgr=0x7fd948012160, pid=-1, src=src@entry=0x7fd98c072c90, dst=dst@entry=0x0) + at ../../src/security/security_manager.c:468 +#1 0x00007fd9646ff0f0 in qemuSecurityMoveImageMetadata (driver=driver@entry=0x7fd948043830, vm=vm@entry=0x7fd98c066db0, src=src@entry=0x7fd98c072c90, + dst=dst@entry=0x0) at ../../src/qemu/qemu_security.c:182 +#2 0x00007fd96462c7b0 in qemuBlockRemoveImageMetadata (driver=driver@entry=0x7fd948043830, vm=vm@entry=0x7fd98c066db0, diskTarget=0x7fd98c072530 "vda", + src=) at ../../src/qemu/qemu_block.c:2628 +#3 0x00007fd9646929d6 in qemuProcessStop (driver=driver@entry=0x7fd948043830, vm=vm@entry=0x7fd98c066db0, reason=reason@entry=VIR_DOMAIN_SHUTOFF_SHUTDOWN, + asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, flags=) at ../../src/qemu/qemu_process.c:7585 +#4 0x00007fd9646fc842 in processMonitorEOFEvent (vm=0x7fd98c066db0, driver=0x7fd948043830) at ../../src/qemu/qemu_driver.c:4794 +#5 qemuProcessEventHandler (data=0x561a93febb60, opaque=0x7fd948043830) at ../../src/qemu/qemu_driver.c:4900 +#6 0x00007fd9a9971a31 in virThreadPoolWorker (opaque=opaque@entry=0x561a93fb58e0) at ../../src/util/virthreadpool.c:163 +(gdb) p mgr->drv +$2 = (virSecurityDriverPtr) 0x0 + +Prior to commit 7cf76d4e3ab, the worker thread pool was freed before +disposing any driver objects. Let's return to that pattern, but leave +the other changes made by 7cf76d4e3ab. + +Signed-off-by: Tamara Schmitz +Signed-off-by: Jim Fehlig +Reviewed-by: Martin Kletzander +--- + src/qemu/qemu_driver.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +Index: libvirt-6.0.0/src/qemu/qemu_driver.c +=================================================================== +--- libvirt-6.0.0.orig/src/qemu/qemu_driver.c ++++ libvirt-6.0.0/src/qemu/qemu_driver.c +@@ -1119,6 +1119,7 @@ qemuStateCleanup(void) + if (!qemu_driver) + return -1; + ++ virThreadPoolFree(qemu_driver->workerPool); + virObjectUnref(qemu_driver->migrationErrors); + virObjectUnref(qemu_driver->closeCallbacks); + virLockManagerPluginUnref(qemu_driver->lockManager); +@@ -1138,7 +1139,6 @@ qemuStateCleanup(void) + ebtablesContextFree(qemu_driver->ebtables); + VIR_FREE(qemu_driver->qemuImgBinary); + virObjectUnref(qemu_driver->domains); +- virThreadPoolFree(qemu_driver->workerPool); + + if (qemu_driver->lockFD != -1) + virPidFileRelease(qemu_driver->config->stateDir, "driver", qemu_driver->lockFD); diff -Nru libvirt-6.0.0/debian/patches/ubuntu/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch libvirt-6.0.0/debian/patches/ubuntu/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch --- libvirt-6.0.0/debian/patches/ubuntu/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-6.0.0/debian/patches/ubuntu/lp2059272-2-qemu-Do-not-save-XML-in-shutdown-on-init.patch 2024-04-16 17:03:03.000000000 +0000 @@ -0,0 +1,290 @@ +Bug-Ubuntu: http://bugs.launchpad.net/bugs/2059272 +Forwarded: not-needed + +From: Mauricio Faria de Oliveira +Date: Fri, 05 Apr 2024 14:36:20 -0300 +Subject: [PATCH] qemu: Do not save domain status XML in + qemuProcessReconnect() if shutdown is requested + +Problem: + +If libvirt is shutdown during initialization (that is unlikely, but may happen), +the QEMU driver's qemuProcessReconnect() threads (used to reconnect to the QEMU +process/monitor of running domains and update the domain status XML accordingly) +may still be running after qemuStateCleanup() freed & zeroed QEMU driver memory. + +This makes the QEMU driver's function pointer/callback to format XML to be NULL, +thus qemuProcessReconnect() -> virDomainObjSave() -> virDomainObjFormat() writes +an incomplete domain status XML file, lacking the QEMU driver specific section, +for example, without the path to the QEMU monitor socket (""). + +The next time libvirtd initializes the QEMU driver, which looks for the domain +status XML files in order to identify the running domains so as to manage them, +there is a parsing error for such XML file, which aborts the identification of +that domain, thus libvirt is not even aware of it, and cannot manage it (e.g., +the domain is not present in `virsh list` nor recognized in `virsh` commands). + +- main() + - daemonStateInit() + - new thread: daemonRunStateInit() + - virStateInitialize() + - qemuStateInitialize() + - driver.xmlopt = virQEMUDriverCreateXMLConf() + - qemuProcessReconnectAll() + - new threads: qemuProcessReconnect() + - virDomainObjSave() + - virDomainObjFormat() + - driver.xmlopt.privateData.format() + - daemonSetupSignals() + - virNetDaemonRun() + - dmn->quit = false + - while (!dmn->quit) + - virEventRunDefaultImpl() + - virStateCleanup() + - qemuStateCleanup() + - unref/free/zero(driver.xmlopt) + +SIG{INT,QUIT,TERM} +- daemonShutdownHandler() + - dmn->quit = true + +Solution in Jammy/upstream: + +It is not sufficient to release (stop) the worker thread pool in order to wait +for the qemuProcessReconnect() threads as they are created independently of the +worker thread pool, with individual/direct calls to virThreadCreate(). + +In Jammy and later there is the .stateShutdownWait() callback (called before the +.stateCleanup() callback, ie, qemuStateCleanup()), which indirectly synchronizes +with qemuProcessReconnect() threads due to virObjectLock() on domain objects. + +However, that callback is not available in Focal, and it is a big change that is +not SRU material (10 patches with significant changes). + +Solution in Focal: + +In theory, the entire qemuProcessReconnect() function should synchronize with +the event loop as 1. shutdown stops it then proceeds to qemuStateCleanup(), and + 2. its calls to QEMU monitor depend on the event loop to get the monitor reply. +(And the QEMU driver memory might be used after release in qemuStateCleanup().) + +In practice, only the call to update XML should synchronize with the event loop, +because it is the actual "commit" of the result of the QEMU monitor calls above. +(This doesn't address the usage of QEMU driver memory after release, admittedly, +but there are no bugs for that yet; and impact is at shutdown time 'only'.) + +Note that, if any of the QEMU monitor calls above block waiting command replies +because the event loop has stopped, the update XML call is not reached. That is +actually OK (since it prevents an incomplete XML) and is what happens currently. + +*But*, if it *is* reached, then it *must* either run with QEMU driver in place +all the way through (so it can write a complete XML file), or *not run* at all. + +So, we can just check whether libvirtd shutdown is set and skip the XML update. + +It is OK to skip the XML update, which runs at libvirtd initialization, because +if a libvirtd shutdown is happening (i.e., an early shutdown) the resulting XML +*is not going to be used anyway* this time / this libvirtd run, and it +*is going to run again anyway* next time / next libvirtd initialization. + +Implementation: + +The libvirtd _daemon_ runs the QEMU _driver_. + +The shutdown handler sets the 'quit' flag in the _daemon_ (stops the event loop) +and this is not accessible by the _driver_, originally. + +However, the daemon passes itself to the driver as an opaque pointer on init, so +the driver can tell it not to shutdown due to timeout, if there are running VMs. + +So, let's use that existing pointer, plus a new function at the daemon level, to +check whether the daemon's 'quit' flag is set (ie, the daemon is shutting down), +and not update the XML in that case. + +The daemon object lock is convenient, as it is used by both the shutdown handler +and the event loop, so if we lock it and 'quit' is not set, the shutdown is not +going to start until we unlock it. Thus, we update the XML with that lock held. + +We also make sure the daemon reference count is correctly (inc/dec)remented in +the qemuProcessReconnect() threads, so that it is not freed/zeroed at shutdown +before we lock it, since we access its memory to take the daemon object lock. + +Details for Makefile.inc.am: + +The plumbing of `virNetDaemonQuitRequested()` from daemon-level to driver-level +needs the RPC include headers and static linking archives/objects, that in turn +need the probes linked (since RPC code has probes). + +(The probes link with `libvirt_driver_qemu_la` not `libvirt_driver_qemu_IMPL_la` +as RPC does because a _test_ already links the probes *and* IMPLementation, thus +would build-fail per duplicate definitions of the probes if IMPL had those too.) + +Index: libvirt-6.0.0/src/qemu/Makefile.inc.am +=================================================================== +--- libvirt-6.0.0.orig/src/qemu/Makefile.inc.am ++++ libvirt-6.0.0/src/qemu/Makefile.inc.am +@@ -99,6 +99,8 @@ libvirt_driver_qemu_impl_la_CFLAGS = \ + -I$(builddir)/access \ + -I$(srcdir)/conf \ + -I$(srcdir)/secret \ ++ -I$(srcdir)/rpc \ ++ -I$(builddir)/rpc \ + $(AM_CFLAGS) \ + $(NULL) + libvirt_driver_qemu_impl_la_LDFLAGS = $(AM_LDFLAGS) +@@ -108,10 +110,13 @@ libvirt_driver_qemu_impl_la_LIBADD = \ + $(LIBNL_LIBS) \ + $(SELINUX_LIBS) \ + $(LIBXML_LIBS) \ ++ libvirt-net-rpc.la \ ++ libvirt-net-rpc-server.la \ + $(NULL) + libvirt_driver_qemu_impl_la_SOURCES = $(QEMU_DRIVER_SOURCES) + + if WITH_DTRACE_PROBES ++libvirt_driver_qemu_la_LIBADD += libvirt_probes.lo + libvirt_driver_qemu_la_LIBADD += libvirt_qemu_probes.lo + nodist_libvirt_driver_qemu_la_SOURCES = libvirt_qemu_probes.h + BUILT_SOURCES += libvirt_qemu_probes.h +Index: libvirt-6.0.0/src/qemu/qemu_driver.c +=================================================================== +--- libvirt-6.0.0.orig/src/qemu/qemu_driver.c ++++ libvirt-6.0.0/src/qemu/qemu_driver.c +@@ -153,6 +153,14 @@ static int qemuOpenFileAs(uid_t fallback + + static virQEMUDriverPtr qemu_driver; + ++/* Store a pointer to the daemon running the QEMU driver. ++ * ++ * Note: that is already in 'qemu_driver->inhibitOpaque', ++ * but it is released and cleared during daemon shutdown. ++ * ++ * This remains in place during shutdown with references. */ ++void *qemu_driver_dmn; ++ + /* Looks up the domain object from snapshot and unlocks the + * driver. The returned domain object is locked and ref'd and the + * caller must call virDomainObjEndAPI() on it. */ +@@ -658,6 +666,7 @@ qemuStateInitialize(bool privileged, + + qemu_driver->inhibitCallback = callback; + qemu_driver->inhibitOpaque = opaque; ++ qemu_driver_dmn = opaque; + + qemu_driver->privileged = privileged; + qemu_driver->hostarch = virArchFromHost(); +Index: libvirt-6.0.0/src/qemu/qemu_process.c +=================================================================== +--- libvirt-6.0.0.orig/src/qemu/qemu_process.c ++++ libvirt-6.0.0/src/qemu/qemu_process.c +@@ -96,6 +96,28 @@ + + VIR_LOG_INIT("qemu.qemu_process"); + ++/* Use the pointer to the daemon running the QEMU driver. ++ * ++ * It is (un)referenced in qemuProcessReconnect{Helper}() ++ * so it has references while qemuProcessReconnect() runs. ++ * ++ * Thus, it can be safely used there even during shutdown. */ ++extern void *qemu_driver_dmn; ++ ++/* Function virNetDaemonQuitRequested() exports whether ++ * a daemon has been requested to shut down (dmn->quit). ++ * ++ * It must be called with the daemon's object lock held ++ * as 'dmn->quit' is set asynchronously under that lock ++ * by signal handlers and it is checked under that lock ++ * for the event loop to continue (or not, if it is set). ++ * ++ * So, it is guaranteed that, if the function return is ++ * false under the daemon lock, the event loop will not ++ * continue or break to shutdown while the lock is held. ++ */ ++#include "rpc/virnetdaemon.h" ++ + /** + * qemuProcessRemoveDomainStatus + * +@@ -8119,8 +8141,27 @@ qemuProcessReconnect(void *opaque) + } + + /* update domain state XML with possibly updated state in virDomainObj */ +- if (virDomainObjSave(obj, driver->xmlopt, cfg->stateDir) < 0) ++ ++ /* ++ * But *not* if shutdown is detected during this initialization ++ * as the QEMU driver XML formatter may have been freed already, ++ * which effectively removes the QEMU information from the file, ++ * causing an error to parse this domain on next initialization. ++ * ++ * The same update will just happen again on next initialization, ++ * and it isn't useful on this initialization as we are shutting ++ * down anyway; so just skip it, do it next time. (LP: #2059272) ++ */ ++ virObjectLock(qemu_driver_dmn); ++ if (virNetDaemonQuitRequested(qemu_driver_dmn)) { ++ VIR_INFO("Leaving the update of '%s' domain status XML for the next " ++ "initialization (shutdown detected on this initialization).", ++ obj->def->name); ++ } else if (virDomainObjSave(obj, driver->xmlopt, cfg->stateDir) < 0) { ++ virObjectUnlock(qemu_driver_dmn); + goto error; ++ } ++ virObjectUnlock(qemu_driver_dmn); + + /* Run an hook to allow admins to do some magic */ + if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { +@@ -8152,6 +8193,7 @@ qemuProcessReconnect(void *opaque) + if (!virDomainObjIsActive(obj)) + qemuDomainRemoveInactiveJob(driver, obj); + } ++ virObjectUnref(qemu_driver_dmn); + virDomainObjEndAPI(&obj); + virNWFilterUnlockFilterUpdates(); + virIdentitySetCurrent(NULL); +@@ -8210,6 +8252,7 @@ qemuProcessReconnectHelper(virDomainObjP + * that handles the reconnect */ + virObjectLock(obj); + virObjectRef(obj); ++ virObjectRef(qemu_driver_dmn); + + if (virThreadCreate(&thread, false, qemuProcessReconnect, data) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", +@@ -8224,6 +8267,7 @@ qemuProcessReconnectHelper(virDomainObjP + QEMU_ASYNC_JOB_NONE, 0); + qemuDomainRemoveInactiveJobLocked(src->driver, obj); + ++ virObjectUnref(qemu_driver_dmn); + virDomainObjEndAPI(&obj); + virNWFilterUnlockFilterUpdates(); + g_clear_object(&data->identity); +Index: libvirt-6.0.0/src/rpc/virnetdaemon.c +=================================================================== +--- libvirt-6.0.0.orig/src/rpc/virnetdaemon.c ++++ libvirt-6.0.0/src/rpc/virnetdaemon.c +@@ -859,6 +859,12 @@ virNetDaemonQuit(virNetDaemonPtr dmn) + virObjectUnlock(dmn); + } + ++bool ++virNetDaemonQuitRequested(virNetDaemonPtr dmn) ++{ ++ return dmn->quit; ++} ++ + static int + daemonServerClose(void *payload, + const void *key G_GNUC_UNUSED, +Index: libvirt-6.0.0/src/rpc/virnetdaemon.h +=================================================================== +--- libvirt-6.0.0.orig/src/rpc/virnetdaemon.h ++++ libvirt-6.0.0/src/rpc/virnetdaemon.h +@@ -68,6 +68,7 @@ void virNetDaemonUpdateServices(virNetDa + void virNetDaemonRun(virNetDaemonPtr dmn); + + void virNetDaemonQuit(virNetDaemonPtr dmn); ++bool virNetDaemonQuitRequested(virNetDaemonPtr dmn); + + void virNetDaemonClose(virNetDaemonPtr dmn); +