Add a flag to the saveFlags function #3

liu-weifeng · 2015-12-23T03:00:44Z

After saveFlags call the domain is paused, then you can make disk snapshot manually.

… is paused, then you can make disk snapshot manually.

While this thread is cleaning up the client and connection objects: libvirt#2 virFileReadAll (path=0x7f28780012b0 "/proc/1319/stat", maxlen=maxlen@entry=1024, buf=buf@entry=0x7f289c60fc40) at util/virfile.c:1287 libvirt#3 0x00007f28adbb1539 in virProcessGetStartTime (pid=<optimized out>, timestamp=timestamp@entry=0x7f289c60fc98) at util/virprocess.c:838 libvirt#4 0x00007f28adb91981 in virIdentityGetSystem () at util/viridentity.c:151 libvirt#5 0x00007f28ae73f17c in remoteClientFreeFunc (data=<optimized out>) at remote.c:1131 libvirt#6 0x00007f28adcb7f33 in virNetServerClientDispose (obj=0x7f28aecad180) at rpc/virnetserverclient.c:858 libvirt#7 0x00007f28adba8eeb in virObjectUnref (anyobj=<optimized out>) at util/virobject.c:265 libvirt#8 0x00007f28ae74ad05 in virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x7f28aec93ff0) at rpc/virnetserver.c:205 libvirt#9 0x00007f28adbbef4e in virThreadPoolWorker (opaque=opaque@entry=0x7f28aec88030) at util/virthreadpool.c:145 In stack frame libvirt#6 the client->identity object got unref'd, but the code that removes the event callbacks in frame libvirt#5 did not run yet as we are trying to obtain the system identity (frames libvirt#4, libvirt#3, libvirt#2). In other thead: #0 virObjectUnref (anyobj=anyobj@entry=0x7f288c162c60) at util/virobject.c:264 klass = 0xdeadbeef obj = 0x7f288c162c60 libvirt#1 0x00007f28ae71c709 in remoteRelayDomainEventCheckACL (client=<optimized out>, conn=<optimized out>, dom=dom@entry=0x7f28aecaafc0) at remote.c:164 libvirt#2 0x00007f28ae71fc83 in remoteRelayDomainEventTrayChange (conn=<optimized out>, dom=0x7f28aecaafc0, ... ) at remote.c:717 libvirt#3 0x00007f28adc04e53 in virDomainEventDispatchDefaultFunc (conn=0x7f287c0009a0, event=0x7f28aecab1a0, ...) at conf/domain_event.c:1455 libvirt#4 0x00007f28adc03831 in virObjectEventStateDispatchCallbacks (callbacks=<optimized out>, ....) at conf/object_event.c:724 libvirt#5 virObjectEventStateQueueDispatch (callbacks=0x7f288c083730, queue=0x7fff51f90030, state=0x7f288c18da20) at conf/object_event.c:738 libvirt#6 virObjectEventStateFlush (state=0x7f288c18da20) at conf/object_event.c:816 libvirt#7 virObjectEventTimer (timer=<optimized out>, opaque=0x7f288c18da20) at conf/object_event.c:562 libvirt#8 0x00007f28adb859cd in virEventPollDispatchTimeouts () at util/vireventpoll.c:459 Frame #0 is unrefing an invalid identity object while frame libvirt#2 hints that the client is still dispatching the event. For untrimmed backtrace see the bugzilla attachment. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1203030 (cherry picked from commit a98129c)

The destination libvirt daemon in a migration may segfault if the client disconnects immediately after the migration has begun: # virsh -c qemu+tls://remote/system list --all Id Name State ---------------------------------------------------- ... # timeout --signal KILL 1 \ virsh migrate example qemu+tls://remote/system \ --verbose --compressed --live --auto-converge \ --abort-on-error --unsafe --persistent \ --undefinesource --copy-storage-all --xml example.xml Killed # virsh -c qemu+tls://remote/system list --all error: failed to connect to the hypervisor error: unable to connect to server at 'remote:16514': Connection refused The crash is in: 1531 void 1532 qemuDomainObjEndJob(virQEMUDriverPtr driver, virDomainObjPtr obj) 1533 { 1534 qemuDomainObjPrivatePtr priv = obj->privateData; 1535 qemuDomainJob job = priv->job.active; 1536 1537 priv->jobs_queued--; Backtrace: #0 at qemuDomainObjEndJob at qemu/qemu_domain.c:1537 libvirt#1 in qemuDomainRemoveInactive at qemu/qemu_domain.c:2497 libvirt#2 in qemuProcessAutoDestroy at qemu/qemu_process.c:5646 libvirt#3 in virCloseCallbacksRun at util/virclosecallbacks.c:350 libvirt#4 in qemuConnectClose at qemu/qemu_driver.c:1154 ... qemuDomainRemoveInactive calls virDomainObjListRemove, which in this case is holding the last remaining reference to the domain. qemuDomainRemoveInactive then calls qemuDomainObjEndJob, but the domain object has been freed and poisoned by then. This patch bumps the domain's refcount until qemuDomainRemoveInactive has completed. We also ensure qemuProcessAutoDestroy does not return the domain to virCloseCallbacksRun to be unlocked in this case. There is similar logic in bhyveProcessAutoDestroy and lxcProcessAutoDestroy (which call virDomainObjListRemove directly). Signed-off-by: Michael Chapman <mike@very.puzzling.org> (cherry picked from commit 7578cc1)

@SiZe

So, after some movement in virt-aa-helper, I've noticed the virt-aa-helper-test failing. I've ran gdb (it took me a while to realize how to do that) and this showed up immediately: Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:106 106 ../sysdeps/x86_64/strlen.S: No such file or directory. (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:106 libvirt#1 0x0000555555561a13 in array_starts_with (str=0x5555557ce910 "/tmp/tmp.6nI2Fkv0KL/1.img", arr=0x7fffffffd160, size=-1540438016) at security/virt-aa-helper.c:525 libvirt#2 0x0000555555561d49 in valid_path (path=0x5555557ce910 "/tmp/tmp.6nI2Fkv0KL/1.img", readonly=false) at security/virt-aa-helper.c:617 libvirt#3 0x0000555555562506 in vah_add_path (buf=0x7fffffffd3e0, path=0x5555557cb910 "/tmp/tmp.6nI2Fkv0KL/1.img", perms=0x555555581585 "rw", recursive=false) at security/virt-aa-helper.c:823 libvirt#4 0x0000555555562693 in vah_add_file (buf=0x7fffffffd3e0, path=0x5555557cb910 "/tmp/tmp.6nI2Fkv0KL/1.img", perms=0x555555581585 "rw") at security/virt-aa-helper.c:854 libvirt#5 0x0000555555562918 in add_file_path (disk=0x5555557d4440, path=0x5555557cb910 "/tmp/tmp.6nI2Fkv0KL/1.img", depth=0, opaque=0x7fffffffd3e0) at security/virt-aa-helper.c:931 libvirt#6 0x00007ffff78f18b1 in virDomainDiskDefForeachPath (disk=0x5555557d4440, ignoreOpenFailure=true, iter=0x5555555628a6 <add_file_path>, opaque=0x7fffffffd3e0) at conf/domain_conf.c:23286 libvirt#7 0x0000555555562b5f in get_files (ctl=0x7fffffffd670) at security/virt-aa-helper.c:982 libvirt#8 0x0000555555564100 in vahParseArgv (ctl=0x7fffffffd670, argc=5, argv=0x7fffffffd7e8) at security/virt-aa-helper.c:1277 libvirt#9 0x00005555555643d6 in main (argc=5, argv=0x7fffffffd7e8) at security/virt-aa-helper.c:1332 So I've taken look at valid_path() because it is obviously calling array_starts_with() with malformed @SiZe. And here's the result: there are two variables to hold the size of three arrays and their value is recalculated before each call of array_starts_with(). What if we just use three variables, initialize them and do not touch them afterwards? Signed-off-by: Michal Privoznik <mprivozn@redhat.com> (cherry picked from commit 52970de)

@SiZe

So, after some movement in virt-aa-helper, I've noticed the virt-aa-helper-test failing. I've ran gdb (it took me a while to realize how to do that) and this showed up immediately: Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:106 106 ../sysdeps/x86_64/strlen.S: No such file or directory. (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:106 libvirt#1 0x0000555555561a13 in array_starts_with (str=0x5555557ce910 "/tmp/tmp.6nI2Fkv0KL/1.img", arr=0x7fffffffd160, size=-1540438016) at security/virt-aa-helper.c:525 libvirt#2 0x0000555555561d49 in valid_path (path=0x5555557ce910 "/tmp/tmp.6nI2Fkv0KL/1.img", readonly=false) at security/virt-aa-helper.c:617 libvirt#3 0x0000555555562506 in vah_add_path (buf=0x7fffffffd3e0, path=0x5555557cb910 "/tmp/tmp.6nI2Fkv0KL/1.img", perms=0x555555581585 "rw", recursive=false) at security/virt-aa-helper.c:823 libvirt#4 0x0000555555562693 in vah_add_file (buf=0x7fffffffd3e0, path=0x5555557cb910 "/tmp/tmp.6nI2Fkv0KL/1.img", perms=0x555555581585 "rw") at security/virt-aa-helper.c:854 libvirt#5 0x0000555555562918 in add_file_path (disk=0x5555557d4440, path=0x5555557cb910 "/tmp/tmp.6nI2Fkv0KL/1.img", depth=0, opaque=0x7fffffffd3e0) at security/virt-aa-helper.c:931 libvirt#6 0x00007ffff78f18b1 in virDomainDiskDefForeachPath (disk=0x5555557d4440, ignoreOpenFailure=true, iter=0x5555555628a6 <add_file_path>, opaque=0x7fffffffd3e0) at conf/domain_conf.c:23286 libvirt#7 0x0000555555562b5f in get_files (ctl=0x7fffffffd670) at security/virt-aa-helper.c:982 libvirt#8 0x0000555555564100 in vahParseArgv (ctl=0x7fffffffd670, argc=5, argv=0x7fffffffd7e8) at security/virt-aa-helper.c:1277 libvirt#9 0x00005555555643d6 in main (argc=5, argv=0x7fffffffd7e8) at security/virt-aa-helper.c:1332 So I've taken look at valid_path() because it is obviously calling array_starts_with() with malformed @SiZe. And here's the result: there are two variables to hold the size of three arrays and their value is recalculated before each call of array_starts_with(). What if we just use three variables, initialize them and do not touch them afterwards? Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

We use the function to create a virDomainXMLOption object that is required for some functions. However, we don't pass the driver pointer to the object anywhere - rather than pass NULL. This causes trouble later when parsing a domain XML and calling post parse callbacks: Program received signal SIGSEGV, Segmentation fault. 0x000000000043fa3e in qemuDomainDefPostParse (def=0x7d36c0, caps=0x7caf10, opaque=0x0) at qemu/qemu_domain.c:1043 1043 qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache, def->emulator); (gdb) bt #0 0x000000000043fa3e in qemuDomainDefPostParse (def=0x7d36c0, caps=0x7caf10, opaque=0x0) at qemu/qemu_domain.c:1043 libvirt#1 0x00007ffff2928bf9 in virDomainDefPostParse (def=0x7d36c0, caps=0x7caf10, xmlopt=0x7c82c0) at conf/domain_conf.c:4269 libvirt#2 0x00007ffff294de04 in virDomainDefParseXML (xml=0x7da8c0, root=0x7dab80, ctxt=0x7da980, caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16400 libvirt#3 0x00007ffff294e5b5 in virDomainDefParseNode (xml=0x7da8c0, root=0x7dab80, caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16582 libvirt#4 0x00007ffff294e424 in virDomainDefParse (xmlStr=0x0, filename=0x7c7ef0 "/home/zippy/work/libvirt/libvirt.git/tests/securityselinuxlabeldata/disks.xml", caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16529 libvirt#5 0x00007ffff294e4b2 in virDomainDefParseFile (filename=0x7c7ef0 "/home/zippy/work/libvirt/libvirt.git/tests/securityselinuxlabeldata/disks.xml", caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16553 libvirt#6 0x00000000004303ca in testSELinuxLoadDef (testname=0x53c929 "disks") at securityselinuxlabeltest.c:192 libvirt#7 0x00000000004309e8 in testSELinuxLabeling (opaque=0x53c929) at securityselinuxlabeltest.c:313 libvirt#8 0x0000000000431207 in virtTestRun (title=0x53c92f "Labelling \"disks\"", body=0x430964 <testSELinuxLabeling>, data=0x53c929) at testutils.c:211 libvirt#9 0x0000000000430c5d in mymain () at securityselinuxlabeltest.c:373 libvirt#10 0x00000000004325c2 in virtTestMain (argc=1, argv=0x7fffffffd7e8, func=0x430b4a <mymain>) at testutils.c:863 libvirt#11 0x0000000000430deb in main (argc=1, argv=0x7fffffffd7e8) at securityselinuxlabeltest.c:381 Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Apparently we are not the only ones with dumb free functions because dbus_message_unref() does not accept NULL either. But if I were to vote, this one is even more evil. Instead of returning an error just like we do it immediately dereference any pointer passed and thus crash you app. Well done DBus! Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f878ebda700 (LWP 31264)] 0x00007f87be4016e5 in ?? () from /usr/lib64/libdbus-1.so.3 (gdb) bt #0 0x00007f87be4016e5 in ?? () from /usr/lib64/libdbus-1.so.3 #1 0x00007f87be3f004e in dbus_message_unref () from /usr/lib64/libdbus-1.so.3 #2 0x00007f87bf6ecf95 in virSystemdGetMachineNameByPID (pid=9849) at util/virsystemd.c:228 #3 0x00007f879761bd4d in qemuConnectCgroup (driver=0x7f87600a32a0, vm=0x7f87600c7550) at qemu/qemu_cgroup.c:909 #4 0x00007f87976386b7 in qemuProcessReconnect (opaque=0x7f87600db840) at qemu/qemu_process.c:3386 #5 0x00007f87bf6edfff in virThreadHelper (data=0x7f87600d5580) at util/virthread.c:206 #6 0x00007f87bb602334 in start_thread (arg=0x7f878ebda700) at pthread_create.c:333 #7 0x00007f87bb3481bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) frame 2 #2 0x00007f87bf6ecf95 in virSystemdGetMachineNameByPID (pid=9849) at util/virsystemd.c:228 228 dbus_message_unref(reply); (gdb) p reply $1 = (DBusMessage *) 0x0 Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

When trying to migrate a huge page enabled guest, I've noticed the following crash. Apparently, if no specific hugepages are requested: <memoryBacking> <hugepages/> </memoryBacking> and there are no hugepages configured on the destination, we try to dereference a NULL pointer. Program received signal SIGSEGV, Segmentation fault. 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 1447 if (virAsprintf(&ret, "%s/libvirt/qemu", hugepage->mnt_dir) < 0) (gdb) bt #0 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 #1 0x00007fcc907fb2f5 in qemuGetDefaultHugepath (hugetlbfs=0x0, nhugetlbfs=0) at qemu/qemu_conf.c:1466 #2 0x00007fcc907b4afa in qemuBuildMemoryBackendStr (size=4194304, pagesize=0, guestNode=0, userNodeset=0x0, autoNodeset=0x0, def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, backendType=0x7fcc95087228, backendProps=0x7fcc95087218, force=false) at qemu/qemu_command.c:3297 #3 0x00007fcc907b4f91 in qemuBuildMemoryCellBackendStr (def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, cell=0, auto_nodeset=0x0, backendStr=0x7fcc70020360) at qemu/qemu_command.c:3413 #4 0x00007fcc907c0406 in qemuBuildNumaArgStr (cfg=0x7fcc5c011800, def=0x7fcc70019070, cmd=0x7fcc700040c0, qemuCaps=0x7fcc70004000, auto_nodeset=0x0) at qemu/qemu_command.c:7470 #5 0x00007fcc907c5fdf in qemuBuildCommandLine (driver=0x7fcc5c07b8a0, logManager=0x7fcc70003c00, def=0x7fcc70019070, monitor_chr=0x7fcc70004bb0, monitor_json=true, qemuCaps=0x7fcc70004000, migrateURI=0x7fcc700199c0 "defer", snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START, standalone=false, enableFips=false, nodeset=0x0, nnicindexes=0x7fcc95087498, nicindexes=0x7fcc950874a0, domainLibDir=0x7fcc700047c0 "/var/lib/libvirt/qemu/domain-1-fedora") at qemu/qemu_command.c:9547 Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Fix xlconfigtest runs build for --enable-test-oom on Xen XL-2-XML Parse channel-pty Program received signal SIGSEGV, Segmentation fault. #0 0x00007ffff3c2b373 in __strchr_sse2 () from /lib64/libc.so.6 ==> #1 0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290 #2 0x00007ffff7875668 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=<optimized out>) at util/virconf.c:306 #3 0x00007ffff78757ef in virConfSaveEntry (buf=buf@entry=0x7fffffffd8a0, cur=cur@entry=0x674780) at util/virconf.c:338 #4 0x00007ffff78783eb in virConfWriteMem (memory=0x665570 "", len=len@entry=0x7fffffffd910, conf=conf@entry=0x65b940) at util/virconf.c:1543 #5 0x000000000040eccb in testCompareParseXML (replaceVars=<optimized out>, xml=<optimized out>, xlcfg=0x662c00 "/home/wtenhave/WORK/libvirt/OOMtesting/libvirt-devel/tests/xlconfigdata/test-channel-pty.cfg") at xlconfigtest.c:108 #6 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205 #7 0x0000000000410b3a in virTestRun (title=title@entry=0x432cc0 "Xen XL-2-XML Parse channel-pty", body=body@entry=0x40e9b0 <testCompareHelper>, data=data@entry=0x7fffffffd9f0) at testutils.c:247 #8 0x000000000040f322 in mymain () at xlconfigtest.c:278 #9 0x0000000000411410 in virTestMain (argc=1, argv=0x7fffffffdba8, func=0x40f660 <mymain>) at testutils.c:992 #10 0x00007ffff3bc0401 in __libc_start_main () from /lib64/libc.so.6 #11 0x000000000040e86a in _start () (gdb) frame 1 #1 0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290 290 if (strchr(val->str, '\n') != NULL) { (gdb) print *val $1 = {type = VIR_CONF_STRING, next = 0x0, l = 0, str = 0x0, list = 0x0} Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>

Fix xlconfigtest runs build for --enable-test-oom on Xen XL-2-XML Parse new-disk #0 0x00007ffff3bd791f in raise () from /lib64/libc.so.6 #1 0x00007ffff3bd951a in abort () from /lib64/libc.so.6 #2 0x00007ffff3c1b200 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff3c2488a in _int_free () from /lib64/libc.so.6 #4 0x00007ffff3c282bc in free () from /lib64/libc.so.6 #5 0x00007ffff7864fcb in virFree (ptrptr=ptrptr@entry=0x7fffffffd868) at util/viralloc.c:582 #6 0x00007ffff78776e5 in virConfFreeValue (val=<optimized out>) at util/virconf.c:178 ==> #7 0x0000000000425759 in xenFormatXLDomainDisks (def=0x7fffffffd8c0, def=0x7fffffffd8c0, conf=0x658220) at xenconfig/xen_xl.c:1159 #8 xenFormatXL (def=def@entry=0x66ec20, conn=conn@entry=0x668cf0) at xenconfig/xen_xl.c:1558 #9 0x000000000040ea1d in testCompareParseXML (replaceVars=<optimized out>, xml=0x65f5e0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.xml", xlcfg=0x65f6b0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.cfg") at xlconfigtest.c:105 #10 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205 #11 0x000000000041079a in virTestRun (title=title@entry=0x431cf0 "Xen XL-2-XML Parse fullvirt-ovmf", body=body@entry=0x40e720 <testCompareHelper>, data=data@entry=0x7fffffffda50) at testutils.c:247 #12 0x000000000040ebc2 in mymain () at xlconfigtest.c:256 #13 0x0000000000411070 in virTestMain (argc=1, argv=0x7fffffffdc08, func=0x40f2c0 <mymain>) at testutils.c:992 #14 0x00007ffff3bc2401 in __libc_start_main () from /lib64/libc.so.6 #15 0x000000000040e5da in _start () symmetry seems missing its sibbling coded functionality demonstrated under functions; xenFormatXLUSBController() xenFormatXLUSB() xenFormatXLDomainChannels() xenFormatXMDisks Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>

Fix xlconfig channel tests when OOM testing is enabled. TEST: xlconfigtest 32) Xen XL-2-XML Format channel-unix ... OK Test OOM for nalloc=55 ................................................*** Error in `/home/jfehlig/virt/upstream/libvirt/tests/.libs/xlconfigtest': double free or corruption (fasttop): 0x0000000000679550 *** ... (gdb) bt #0 0x00007ffff36875af in raise () from /lib64/libc.so.6 #1 0x00007ffff36889aa in abort () from /lib64/libc.so.6 #2 0x00007ffff36c5150 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff36cb4f6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007ffff36cbcee in _int_free () from /lib64/libc.so.6 #5 0x00007ffff782babf in virFree (ptrptr=0x7fffffffdca8) at util/viralloc.c:582 #6 0x000000000042f2f3 in xenParseXLChannel (conf=0x677350, def=0x6815b0) at xenconfig/xen_xl.c:788 #7 0x000000000042f44e in xenParseXL (conf=0x677350, caps=0x6832b0, xmlopt=0x67f6e0) at xenconfig/xen_xl.c:828 #8 0x00000000004105a3 in testCompareFormatXML ( xlcfg=0x6811e0 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.cfg", xml=0x681110 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.xml", replaceVars=false) at xlconfigtest.c:152 When a channel is successfully parsed and its path and name fields assigned from local variables, set the local variables to NULL to prevent a double free on error. Signed-off-by: Jim Fehlig <jfehlig@suse.com>

ka maybe have been freeed in virObjectUnref, application using virKeepAliveTimer will segfault when unlock ka. We should keep ka's refs positive before using it. #0 0x00007fd8f79970e8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fd8e8001b80) at util/virobject.c:169 #1 0x00007fd8f799742e in virObjectIsClass (anyobj=anyobj entry=0x7fd8e800b9c0, klass=＜optimized out＞) at util/virobject.c:365 #2 0x00007fd8f79974e4 in virObjectUnlock (anyobj=0x7fd8e800b9c0) at util/virobject.c:338 #3 0x00007fd8f7ac477e in virKeepAliveTimer (timer=＜optimized out＞, opaque=0x7fd8e800b9c0) at rpc/virkeepalive.c:177 #4 0x00007fd8f7e5c9cf in libvirt_virEventInvokeTimeoutCallback () from /usr/lib64/python2.7/site-packages/libvirtmod.so #5 0x00007fd8ff64db94 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #6 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #7 0x00007fd8ff64d85f in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #8 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #9 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #10 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #11 0x00007fd8ff5dc098 in function_call () from /lib64/libpython2.7.so.1.0 #12 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #13 0x00007fd8ff5c6085 in instancemethod_call () from /lib64/libpython2.7.so.1.0 #14 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #15 0x00007fd8ff648ff7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0 #16 0x00007fd8ff67d7e2 in t_bootstrap () from /lib64/libpython2.7.so.1.0 #17 0x00007fd8ff358df3 in start_thread () from /lib64/libpthread.so.0 #18 0x00007fd8fe97d3ed in clone () from /lib64/libc.so.6 Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Based upon an idea and some research by Wang King <king.wang@huawei.com> and xinhua.Cao <caoxinhua@huawei.com>. Since we're assigning the 'client' to our callback event lookaside list, it's imperative that we grab a reference to the object; otherwise, when the object is unref'd during virNetServerProcessClients when it's determined that the virNetServerClientIsClosed and the memory is free'd before perhaps the object event state callbacks are run. When a virObjectLock() is run, before sending the message the following trace occurs; #0 0x00007fda223d66d8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fda24c81b40) at util/virobject.c:169 #1 0x00007fda223d6a1e in virObjectIsClass (anyobj=anyobj@entry=0x7fd9e575b400, klass=<optimized out>) at util/virobject.c:365 #2 0x00007fda223d6a44 in virObjectLock (anyobj=0x7fd9e575b400) at util/virobject.c:317 #3 0x00007fda22507f71 in virNetServerClientSendMessage (client=client@entry=0x7fd9e575b400, msg=msg@entry=0x7fd9ec30de90) at rpc/virnetserverclient.c:1422 #4 0x00007fda230d714d in remoteDispatchObjectEventSend (client=0x7fd9e575b400, program=0x7fda24c844e0, procnr=348, proc=0x7fda2310e5e0 <xdr_remote_domain_event_callback_tunable_msg>, data=0x7ffc3857fdb0) at remote.c:3803 #5 0x00007fda230dd71b in remoteRelayDomainEventTunable (conn=<optimized out>, dom=0x7fda27cd7660, params=0x7fda27f3aae0, nparams=1,opaque=0x7fd9e6c99e00) at remote.c:1033 #6 0x00007fda224484cb in virDomainEventDispatchDefaultFunc (conn=0x7fda27cd0120, event=0x7fda2736ea00, cb=0x7fda230dd610 <remoteRelayDomainEventTunable>, cbopaque=0x7fd9e6c99e00) at conf/domain_event.c:1910 #7 0x00007fda22446871 in virObjectEventStateDispatchCallbacks (callbacks=<optimized out>, callbacks=<optimized out>, event=0x7fda2736ea00,state=0x7fda24ca3960) at conf/object_event.c:722 #8 virObjectEventStateQueueDispatch (callbacks=0x7fda24c65800, queue=0x7ffc3857fe90, state=0x7fda24ca3960) at conf/object_event.c:736 #9 virObjectEventStateFlush (state=0x7fda24ca3960) at conf/object_event.c:814 #10 virObjectEventTimer (timer=<optimized out>, opaque=0x7fda24ca3960) at conf/object_event.c:560 #11 0x00007fda223ae8b9 in virEventPollDispatchTimeouts () at util/vireventpoll.c:458 #12 virEventPollRunOnce () at util/vireventpoll.c:654 #13 0x00007fda223ad1d2 in virEventRunDefaultImpl () at util/virevent.c:314 #14 0x00007fda225046cd in virNetDaemonRun (dmn=0x7fda24c775c0) at rpc/virnetdaemon.c:818 #15 0x00007fda230d6351 in main (argc=<optimized out>, argv=<optimized out>) at libvirtd.c:1623 Signed-off-by: John Ferlan <jferlan@redhat.com>

When trying to migrate a huge page enabled guest, I've noticed the following crash. Apparently, if no specific hugepages are requested: <memoryBacking> <hugepages/> </memoryBacking> and there are no hugepages configured on the destination, we try to dereference a NULL pointer. Program received signal SIGSEGV, Segmentation fault. 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 1447 if (virAsprintf(&ret, "%s/libvirt/qemu", hugepage->mnt_dir) < 0) (gdb) bt #0 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 libvirt#1 0x00007fcc907fb2f5 in qemuGetDefaultHugepath (hugetlbfs=0x0, nhugetlbfs=0) at qemu/qemu_conf.c:1466 libvirt#2 0x00007fcc907b4afa in qemuBuildMemoryBackendStr (size=4194304, pagesize=0, guestNode=0, userNodeset=0x0, autoNodeset=0x0, def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, backendType=0x7fcc95087228, backendProps=0x7fcc95087218, force=false) at qemu/qemu_command.c:3297 libvirt#3 0x00007fcc907b4f91 in qemuBuildMemoryCellBackendStr (def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, cell=0, auto_nodeset=0x0, backendStr=0x7fcc70020360) at qemu/qemu_command.c:3413 libvirt#4 0x00007fcc907c0406 in qemuBuildNumaArgStr (cfg=0x7fcc5c011800, def=0x7fcc70019070, cmd=0x7fcc700040c0, qemuCaps=0x7fcc70004000, auto_nodeset=0x0) at qemu/qemu_command.c:7470 libvirt#5 0x00007fcc907c5fdf in qemuBuildCommandLine (driver=0x7fcc5c07b8a0, logManager=0x7fcc70003c00, def=0x7fcc70019070, monitor_chr=0x7fcc70004bb0, monitor_json=true, qemuCaps=0x7fcc70004000, migrateURI=0x7fcc700199c0 "defer", snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START, standalone=false, enableFips=false, nodeset=0x0, nnicindexes=0x7fcc95087498, nicindexes=0x7fcc950874a0, domainLibDir=0x7fcc700047c0 "/var/lib/libvirt/qemu/domain-1-fedora") at qemu/qemu_command.c:9547 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> (cherry picked from commit 647db05)

When trying to migrate a huge page enabled guest, I've noticed the following crash. Apparently, if no specific hugepages are requested: <memoryBacking> <hugepages/> </memoryBacking> and there are no hugepages configured on the destination, we try to dereference a NULL pointer. Program received signal SIGSEGV, Segmentation fault. 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 1447 if (virAsprintf(&ret, "%s/libvirt/qemu", hugepage->mnt_dir) < 0) (gdb) bt #0 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 #1 0x00007fcc907fb2f5 in qemuGetDefaultHugepath (hugetlbfs=0x0, nhugetlbfs=0) at qemu/qemu_conf.c:1466 #2 0x00007fcc907b4afa in qemuBuildMemoryBackendStr (size=4194304, pagesize=0, guestNode=0, userNodeset=0x0, autoNodeset=0x0, def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, backendType=0x7fcc95087228, backendProps=0x7fcc95087218, force=false) at qemu/qemu_command.c:3297 #3 0x00007fcc907b4f91 in qemuBuildMemoryCellBackendStr (def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, cell=0, auto_nodeset=0x0, backendStr=0x7fcc70020360) at qemu/qemu_command.c:3413 #4 0x00007fcc907c0406 in qemuBuildNumaArgStr (cfg=0x7fcc5c011800, def=0x7fcc70019070, cmd=0x7fcc700040c0, qemuCaps=0x7fcc70004000, auto_nodeset=0x0) at qemu/qemu_command.c:7470 #5 0x00007fcc907c5fdf in qemuBuildCommandLine (driver=0x7fcc5c07b8a0, logManager=0x7fcc70003c00, def=0x7fcc70019070, monitor_chr=0x7fcc70004bb0, monitor_json=true, qemuCaps=0x7fcc70004000, migrateURI=0x7fcc700199c0 "defer", snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START, standalone=false, enableFips=false, nodeset=0x0, nnicindexes=0x7fcc95087498, nicindexes=0x7fcc950874a0, domainLibDir=0x7fcc700047c0 "/var/lib/libvirt/qemu/domain-1-fedora") at qemu/qemu_command.c:9547 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> (cherry picked from commit 647db05)

Fix xlconfigtest runs build for --enable-test-oom on Xen XL-2-XML Parse channel-pty Program received signal SIGSEGV, Segmentation fault. #0 0x00007ffff3c2b373 in __strchr_sse2 () from /lib64/libc.so.6 ==> #1 0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290 #2 0x00007ffff7875668 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=<optimized out>) at util/virconf.c:306 #3 0x00007ffff78757ef in virConfSaveEntry (buf=buf@entry=0x7fffffffd8a0, cur=cur@entry=0x674780) at util/virconf.c:338 #4 0x00007ffff78783eb in virConfWriteMem (memory=0x665570 "", len=len@entry=0x7fffffffd910, conf=conf@entry=0x65b940) at util/virconf.c:1543 #5 0x000000000040eccb in testCompareParseXML (replaceVars=<optimized out>, xml=<optimized out>, xlcfg=0x662c00 "/home/wtenhave/WORK/libvirt/OOMtesting/libvirt-devel/tests/xlconfigdata/test-channel-pty.cfg") at xlconfigtest.c:108 #6 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205 #7 0x0000000000410b3a in virTestRun (title=title@entry=0x432cc0 "Xen XL-2-XML Parse channel-pty", body=body@entry=0x40e9b0 <testCompareHelper>, data=data@entry=0x7fffffffd9f0) at testutils.c:247 #8 0x000000000040f322 in mymain () at xlconfigtest.c:278 #9 0x0000000000411410 in virTestMain (argc=1, argv=0x7fffffffdba8, func=0x40f660 <mymain>) at testutils.c:992 #10 0x00007ffff3bc0401 in __libc_start_main () from /lib64/libc.so.6 #11 0x000000000040e86a in _start () (gdb) frame 1 #1 0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290 290 if (strchr(val->str, '\n') != NULL) { (gdb) print *val $1 = {type = VIR_CONF_STRING, next = 0x0, l = 0, str = 0x0, list = 0x0} Signed-off-by: Wim ten Have <wim.ten.have@oracle.com> (cherry picked from commit ae5d758)

Fix xlconfigtest runs build for --enable-test-oom on Xen XL-2-XML Parse new-disk #0 0x00007ffff3bd791f in raise () from /lib64/libc.so.6 #1 0x00007ffff3bd951a in abort () from /lib64/libc.so.6 #2 0x00007ffff3c1b200 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff3c2488a in _int_free () from /lib64/libc.so.6 #4 0x00007ffff3c282bc in free () from /lib64/libc.so.6 #5 0x00007ffff7864fcb in virFree (ptrptr=ptrptr@entry=0x7fffffffd868) at util/viralloc.c:582 #6 0x00007ffff78776e5 in virConfFreeValue (val=<optimized out>) at util/virconf.c:178 ==> #7 0x0000000000425759 in xenFormatXLDomainDisks (def=0x7fffffffd8c0, def=0x7fffffffd8c0, conf=0x658220) at xenconfig/xen_xl.c:1159 #8 xenFormatXL (def=def@entry=0x66ec20, conn=conn@entry=0x668cf0) at xenconfig/xen_xl.c:1558 #9 0x000000000040ea1d in testCompareParseXML (replaceVars=<optimized out>, xml=0x65f5e0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.xml", xlcfg=0x65f6b0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.cfg") at xlconfigtest.c:105 #10 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205 #11 0x000000000041079a in virTestRun (title=title@entry=0x431cf0 "Xen XL-2-XML Parse fullvirt-ovmf", body=body@entry=0x40e720 <testCompareHelper>, data=data@entry=0x7fffffffda50) at testutils.c:247 #12 0x000000000040ebc2 in mymain () at xlconfigtest.c:256 #13 0x0000000000411070 in virTestMain (argc=1, argv=0x7fffffffdc08, func=0x40f2c0 <mymain>) at testutils.c:992 #14 0x00007ffff3bc2401 in __libc_start_main () from /lib64/libc.so.6 #15 0x000000000040e5da in _start () symmetry seems missing its sibbling coded functionality demonstrated under functions; xenFormatXLUSBController() xenFormatXLUSB() xenFormatXLDomainChannels() xenFormatXMDisks Signed-off-by: Wim ten Have <wim.ten.have@oracle.com> (cherry picked from commit 2c1a31a)

Fix xlconfig channel tests when OOM testing is enabled. TEST: xlconfigtest 32) Xen XL-2-XML Format channel-unix ... OK Test OOM for nalloc=55 ................................................*** Error in `/home/jfehlig/virt/upstream/libvirt/tests/.libs/xlconfigtest': double free or corruption (fasttop): 0x0000000000679550 *** ... (gdb) bt #0 0x00007ffff36875af in raise () from /lib64/libc.so.6 #1 0x00007ffff36889aa in abort () from /lib64/libc.so.6 #2 0x00007ffff36c5150 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff36cb4f6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007ffff36cbcee in _int_free () from /lib64/libc.so.6 #5 0x00007ffff782babf in virFree (ptrptr=0x7fffffffdca8) at util/viralloc.c:582 #6 0x000000000042f2f3 in xenParseXLChannel (conf=0x677350, def=0x6815b0) at xenconfig/xen_xl.c:788 #7 0x000000000042f44e in xenParseXL (conf=0x677350, caps=0x6832b0, xmlopt=0x67f6e0) at xenconfig/xen_xl.c:828 #8 0x00000000004105a3 in testCompareFormatXML ( xlcfg=0x6811e0 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.cfg", xml=0x681110 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.xml", replaceVars=false) at xlconfigtest.c:152 When a channel is successfully parsed and its path and name fields assigned from local variables, set the local variables to NULL to prevent a double free on error. Signed-off-by: Jim Fehlig <jfehlig@suse.com> (cherry picked from commit b2c12f5)

ka maybe have been freeed in virObjectUnref, application using virKeepAliveTimer will segfault when unlock ka. We should keep ka's refs positive before using it. #0 0x00007fd8f79970e8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fd8e8001b80) at util/virobject.c:169 #1 0x00007fd8f799742e in virObjectIsClass (anyobj=anyobj entry=0x7fd8e800b9c0, klass=＜optimized out＞) at util/virobject.c:365 #2 0x00007fd8f79974e4 in virObjectUnlock (anyobj=0x7fd8e800b9c0) at util/virobject.c:338 #3 0x00007fd8f7ac477e in virKeepAliveTimer (timer=＜optimized out＞, opaque=0x7fd8e800b9c0) at rpc/virkeepalive.c:177 #4 0x00007fd8f7e5c9cf in libvirt_virEventInvokeTimeoutCallback () from /usr/lib64/python2.7/site-packages/libvirtmod.so #5 0x00007fd8ff64db94 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #6 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #7 0x00007fd8ff64d85f in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #8 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #9 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #10 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #11 0x00007fd8ff5dc098 in function_call () from /lib64/libpython2.7.so.1.0 #12 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #13 0x00007fd8ff5c6085 in instancemethod_call () from /lib64/libpython2.7.so.1.0 #14 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #15 0x00007fd8ff648ff7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0 #16 0x00007fd8ff67d7e2 in t_bootstrap () from /lib64/libpython2.7.so.1.0 #17 0x00007fd8ff358df3 in start_thread () from /lib64/libpthread.so.0 #18 0x00007fd8fe97d3ed in clone () from /lib64/libc.so.6 Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> (cherry picked from commit ab5bb6f)

@freeCB

If a remote call fails during event registration (more than likely from a network failure or remote libvirtd restart timed just right), then when calling the virObjectEventStateDeregisterID we don't want to call the registered @freeCB function because that breaks our contract that we would only call it after succesfully returning. If the @freeCB routine were called, it could result in a double free from properly coded applications that free their opaque data on failure to register, as seen in the following details: Program terminated with signal 6, Aborted. #0 0x00007fc45cba15d7 in raise #1 0x00007fc45cba2cc8 in abort #2 0x00007fc45cbe12f7 in __libc_message #3 0x00007fc45cbe86d3 in _int_free #4 0x00007fc45d8d292c in PyDict_Fini #5 0x00007fc45d94f46a in Py_Finalize #6 0x00007fc45d960735 in Py_Main #7 0x00007fc45cb8daf5 in __libc_start_main #8 0x0000000000400721 in _start The double dereference of 'pyobj_cbData' is triggered in the following way: (1) libvirt_virConnectDomainEventRegisterAny is invoked. (2) the event is successfully added to the event callback list (virDomainEventStateRegisterClient in remoteConnectDomainEventRegisterAny returns 1 which means ok). (3) when function remoteConnectDomainEventRegisterAny is hit, network connection disconnected coincidently (or libvirtd is restarted) in the context of function 'call' then the connection is lost and the function 'call' failed, the branch virObjectEventStateDeregisterID is therefore taken. (4) 'pyobj_conn' is dereferenced the 1st time in libvirt_virConnectDomainEventFreeFunc. (5) 'pyobj_cbData' (refered to pyobj_conn) is dereferenced the 2nd time in libvirt_virConnectDomainEventRegisterAny. (6) the double free error is triggered. Resolve this by adding a @doFreeCb boolean in order to avoid calling the freeCb in virObjectEventStateDeregisterID for any remote call failure in a remoteConnect*EventRegister* API. For remoteConnect*EventDeregister* calls, the passed value would be true indicating they should run the freecb if it exists; whereas, it's false for the remote call failure path. Patch based on the investigation and initial patch posted by fangying <fangying1@huawei.com>.

Direct leak of 104 byte(s) in 1 object(s) allocated from: #0 0x7f904bfbe12b (/lib64/liblsan.so.0+0xe12b) #1 0x7f904ba0ad67 in virAlloc ../../src/util/viralloc.c:144 #2 0x7f904bbc11a4 in virNetMessageNew ../../src/rpc/virnetmessage.c:42 #3 0x7f904bbb8e77 in virNetServerClientNewInternal ../../src/rpc/virnetserverclient.c:392 #4 0x7f904bbb9921 in virNetServerClientNew ../../src/rpc/virnetserverclient.c:440 #5 0x402ce5 in testIdentity ../../tests/virnetserverclienttest.c:55 #6 0x403bed in virTestRun ../../tests/testutils.c:180 #7 0x402c1e in mymain ../../tests/virnetserverclienttest.c:146 #8 0x404c80 in virTestMain ../../tests/testutils.c:1119 #9 0x4030d5 in main ../../tests/virnetserverclienttest.c:152 #10 0x7f9047f7f889 in __libc_start_main (/lib64/libc.so.6+0x20889) Indirect leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f904bfbe12b (/lib64/liblsan.so.0+0xe12b) #1 0x7f904ba0adc7 in virAllocN ../../src/util/viralloc.c:191 #2 0x7f904bbb8ec7 in virNetServerClientNewInternal ../../src/rpc/virnetserverclient.c:395 #3 0x7f904bbb9921 in virNetServerClientNew ../../src/rpc/virnetserverclient.c:440 #4 0x402ce5 in testIdentity ../../tests/virnetserverclienttest.c:55 #5 0x403bed in virTestRun ../../tests/testutils.c:180 #6 0x402c1e in mymain ../../tests/virnetserverclienttest.c:146 #7 0x404c80 in virTestMain ../../tests/testutils.c:1119 #8 0x4030d5 in main ../../tests/virnetserverclienttest.c:152 #9 0x7f9047f7f889 in __libc_start_main (/lib64/libc.so.6+0x20889) SUMMARY: LeakSanitizer: 108 byte(s) leaked in 2 allocation(s). Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>

The fix for CVE-2018-6764 introduced a potential deadlock scenario that gets triggered by the NSS module when virGetHostname() calls getaddrinfo to resolve the hostname: #0 0x00007f6e714b57e7 in futex_wait #1 futex_wait_simple #2 __pthread_once_slow #3 0x00007f6e71d16e7d in virOnce #4 0x00007f6e71d0997c in virLogInitialize #5 0x00007f6e71d0a09a in virLogVMessage #6 0x00007f6e71d09ffd in virLogMessage #7 0x00007f6e71d0db22 in virObjectNew #8 0x00007f6e71d0dbf1 in virObjectLockableNew #9 0x00007f6e71d0d3e5 in virMacMapNew #10 0x00007f6e71cdc50a in findLease #11 0x00007f6e71cdcc56 in _nss_libvirt_gethostbyname4_r #12 0x00007f6e724631fc in gaih_inet libvirt#13 0x00007f6e72464697 in __GI_getaddrinfo libvirt#14 0x00007f6e71d19e81 in virGetHostnameImpl libvirt#15 0x00007f6e71d1a057 in virGetHostnameQuiet libvirt#16 0x00007f6e71d09936 in virLogOnceInit libvirt#17 0x00007f6e71d09952 in virLogOnce libvirt#18 0x00007f6e714b5829 in __pthread_once_slow libvirt#19 0x00007f6e71d16e7d in virOnce libvirt#20 0x00007f6e71d0997c in virLogInitialize libvirt#21 0x00007f6e71d0a09a in virLogVMessage libvirt#22 0x00007f6e71d09ffd in virLogMessage libvirt#23 0x00007f6e71d0db22 in virObjectNew libvirt#24 0x00007f6e71d0dbf1 in virObjectLockableNew libvirt#25 0x00007f6e71d0d3e5 in virMacMapNew libvirt#26 0x00007f6e71cdc50a in findLease libvirt#27 0x00007f6e71cdc839 in _nss_libvirt_gethostbyname3_r libvirt#28 0x00007f6e71cdc724 in _nss_libvirt_gethostbyname2_r libvirt#29 0x00007f6e7248f72f in __gethostbyname2_r libvirt#30 0x00007f6e7248f494 in gethostbyname2 libvirt#31 0x000056348c30c36d in hosts_keys libvirt#32 0x000056348c30b7d2 in main Fortunately the extra stuff virGetHostname does is totally irrelevant to the needs of the logging code, so we can just inline a call to the native hostname() syscall directly. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

The fix for CVE-2018-6764 introduced a potential deadlock scenario that gets triggered by the NSS module when virGetHostname() calls getaddrinfo to resolve the hostname: #0 0x00007f6e714b57e7 in futex_wait #1 futex_wait_simple #2 __pthread_once_slow #3 0x00007f6e71d16e7d in virOnce #4 0x00007f6e71d0997c in virLogInitialize #5 0x00007f6e71d0a09a in virLogVMessage F438 #6 0x00007f6e71d09ffd in virLogMessage #7 0x00007f6e71d0db22 in virObjectNew #8 0x00007f6e71d0dbf1 in virObjectLockableNew #9 0x00007f6e71d0d3e5 in virMacMapNew #10 0x00007f6e71cdc50a in findLease #11 0x00007f6e71cdcc56 in _nss_libvirt_gethostbyname4_r #12 0x00007f6e724631fc in gaih_inet #13 0x00007f6e72464697 in __GI_getaddrinfo #14 0x00007f6e71d19e81 in virGetHostnameImpl #15 0x00007f6e71d1a057 in virGetHostnameQuiet #16 0x00007f6e71d09936 in virLogOnceInit #17 0x00007f6e71d09952 in virLogOnce #18 0x00007f6e714b5829 in __pthread_once_slow #19 0x00007f6e71d16e7d in virOnce #20 0x00007f6e71d0997c in virLogInitialize #21 0x00007f6e71d0a09a in virLogVMessage #22 0x00007f6e71d09ffd in virLogMessage #23 0x00007f6e71d0db22 in virObjectNew #24 0x00007f6e71d0dbf1 in virObjectLockableNew #25 0x00007f6e71d0d3e5 in virMacMapNew #26 0x00007f6e71cdc50a in findLease #27 0x00007f6e71cdc839 in _nss_libvirt_gethostbyname3_r #28 0x00007f6e71cdc724 in _nss_libvirt_gethostbyname2_r #29 0x00007f6e7248f72f in __gethostbyname2_r #30 0x00007f6e7248f494 in gethostbyname2 #31 0x000056348c30c36d in hosts_keys #32 0x000056348c30b7d2 in main Fortunately the extra stuff virGetHostname does is totally irrelevant to the needs of the logging code, so we can just inline a call to the native hostname() syscall directly. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit c2dc669)

The fix for CVE-2018-6764 introduced a potential deadlock scenario that gets triggered by the NSS module when virGetHostname() calls getaddrinfo to resolve the hostname: #0 0x00007f6e714b57e7 in futex_wait libvirt#1 futex_wait_simple libvirt#2 __pthread_once_slow libvirt#3 0x00007f6e71d16e7d in virOnce libvirt#4 0x00007f6e71d0997c in virLogInitialize libvirt#5 0x00007f6e71d0a09a in virLogVMessage libvirt#6 0x00007f6e71d09ffd in virLogMessage libvirt#7 0x00007f6e71d0db22 in virObjectNew libvirt#8 0x00007f6e71d0dbf1 in virObjectLockableNew libvirt#9 0x00007f6e71d0d3e5 in virMacMapNew libvirt#10 0x00007f6e71cdc50a in findLease libvirt#11 0x00007f6e71cdcc56 in _nss_libvirt_gethostbyname4_r libvirt#12 0x00007f6e724631fc in gaih_inet libvirt#13 0x00007f6e72464697 in __GI_getaddrinfo libvirt#14 0x00007f6e71d19e81 in virGetHostnameImpl libvirt#15 0x00007f6e71d1a057 in virGetHostnameQuiet libvirt#16 0x00007f6e71d09936 in virLogOnceInit libvirt#17 0x00007f6e71d09952 in virLogOnce libvirt#18 0x00007f6e714b5829 in __pthread_once_slow libvirt#19 0x00007f6e71d16e7d in virOnce libvirt#20 0x00007f6e71d0997c in virLogInitialize libvirt#21 0x00007f6e71d0a09a in virLogVMessage libvirt#22 0x00007f6e71d09ffd in virLogMessage libvirt#23 0x00007f6e71d0db22 in virObjectNew libvirt#24 0x00007f6e71d0dbf1 in virObjectLockableNew libvirt#25 0x00007f6e71d0d3e5 in virMacMapNew libvirt#26 0x00007f6e71cdc50a in findLease libvirt#27 0x00007f6e71cdc839 in _nss_libvirt_gethostbyname3_r libvirt#28 0x00007f6e71cdc724 in _nss_libvirt_gethostbyname2_r libvirt#29 0x00007f6e7248f72f in __gethostbyname2_r libvirt#30 0x00007f6e7248f494 in gethostbyname2 libvirt#31 0x000056348c30c36d in hosts_keys libvirt#32 0x000056348c30b7d2 in main Fortunately the extra stuff virGetHostname does is totally irrelevant to the needs of the logging code, so we can just inline a call to the native hostname() syscall directly. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit c2dc669)

Currently if the virNetServer instance is created with max_workers==0 to request a non-threaded dispatch process, we deadlock during dispatch #0 0x00007fb845f6f42d in __lll_lock_wait () from /lib64/libpthread.so.0 libvirt#1 0x00007fb845f681d3 in pthread_mutex_lock () from /lib64/libpthread.so.0 libvirt#2 0x000055a6628bb305 in virMutexLock (m=<optimized out>) at util/virthread.c:89 libvirt#3 0x000055a6628a984b in virObjectLock (anyobj=<optimized out>) at util/virobject.c:435 libvirt#4 0x000055a66286fcde in virNetServerClientIsAuthenticated (client=client@entry=0x55a663a7b960) at rpc/virnetserverclient.c:1565 libvirt#5 0x000055a66286cc17 in virNetServerProgramDispatchCall (msg=0x55a663a7bc50, client=0x55a663a7b960, server=0x55a663a77550, prog=0x55a663a78020) at rpc/virnetserverprogram.c:407 libvirt#6 virNetServerProgramDispatch (prog=prog@entry=0x55a663a78020, server=server@entry=0x55a663a77550, client=client@entry=0x55a663a7b960, msg=msg@entry=0x55a663a7bc50) at rpc/virnetserverprogram.c:307 libvirt#7 0x000055a662871d56 in virNetServerProcessMsg (msg=0x55a663a7bc50, prog=0x55a663a78020, client=0x55a663a7b960, srv=0x55a663a77550) at rpc/virnetserver.c:148 libvirt#8 virNetServerDispatchNewMessage (client=0x55a663a7b960, msg=0x55a663a7bc50, opaque=0x55a663a77550) at rpc/virnetserver.c:227 libvirt#9 0x000055a66286e4c0 in virNetServerClientDispatchRead (client=client@entry=0x55a663a7b960) at rpc/virnetserverclient.c:1322 libvirt#10 0x000055a66286e813 in virNetServerClientDispatchEvent (sock=<optimized out>, events=1, opaque=0x55a663a7b960) at rpc/virnetserverclient.c:1507 libvirt#11 0x000055a662899be0 in virEventPollDispatchHandles (fds=0x55a663a7bdc0, nfds=<optimized out>) at util/vireventpoll.c:508 libvirt#12 virEventPollRunOnce () at util/vireventpoll.c:657 libvirt#13 0x000055a6628982f1 in virEventRunDefaultImpl () at util/virevent.c:327 libvirt#14 0x000055a6628716d5 in virNetDaemonRun (dmn=0x55a663a771b0) at rpc/virnetdaemon.c:858 libvirt#15 0x000055a662864c1d in main (argc=<optimized out>, #argv=0x7ffd105b4838) at logging/log_daemon.c:1235 Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

On start up of libvirtd the worker pool of the QEMU driver must be initialized before trying to reconnect to all the running QEMU instances. Otherwise segmentation faults can occur if there are QEMU monitor events emitted. #0 __GI___pthread_mutex_lock #1 0x000003fffdba9e62 in virMutexLock #2 0x000003fffdbab2dc in virThreadPoolSendJob #3 0x000003ffd8343b70 in qemuProcessHandleSerialChanged #4 0x000003ffd836a776 in qemuMonitorEmitSerialChange #5 0x000003ffd8378e52 in qemuMonitorJSONHandleSerialChange #6 0x000003ffd8378930 in qemuMonitorJSONIOProcessEvent #7 0x000003ffd837edee in qemuMonitorJSONIOProcessLine #8 0x000003ffd837ef86 in qemuMonitorJSONIOProcess #9 0x000003ffd836757a in qemuMonitorIOProcess #10 0x000003ffd836863e in qemuMonitorIO #11 0x000003fffdb4033a in virEventPollDispatchHandles #12 0x000003fffdb4055e in virEventPollRunOnce #13 0x000003fffdb3e782 in virEventRunDefaultImpl #14 0x000003fffdc89400 in virNetDaemonRun #15 0x000000010002a816 in main Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>

Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams libvirt#1 qemuNodeGetSEVInfo libvirt#2 virNodeGetSEVInfo libvirt#3 remoteDispatchNodeGetSevInfo libvirt#4 remoteDispatchNodeGetSevInfoHelper libvirt#5 virNetServerProgramDispatchCall libvirt#6 virNetServerProgramDispatch libvirt#7 virNetServerProcessMsg libvirt#8 virNetServerHandleJob libvirt#9 virThreadPoolWorker libvirt#10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>

@vm

If @vm has flagged as "to be removed" virDomainObjListFindByNameLocked returns NULL (although the definition actually exists). Therefore, the possibility exits that "virHashAddEntry" will raise the error "Duplicate key" => virDomainObjListAddObjLocked fails => virDomainObjEndAPI(&vm) is called and this leads to a freeing of @def since @def is already assigned to vm->def. But actually this leads to a double free since the common usage pattern is that the caller of virDomainObjListAdd(Locked) is responsible for freeing @def in case of an error. Let's fix this by setting vm->def to NULL in case of an error. Backtrace: ➤ bt #0 virFree (ptrptr=0x7575757575757575) libvirt#1 0x000003ffb5b25b3e in virDomainResourceDefFree libvirt#2 0x000003ffb5b37c34 in virDomainDefFree libvirt#3 0x000003ff9123f734 in qemuDomainDefineXMLFlags libvirt#4 0x000003ff9123f7f4 in qemuDomainDefineXML libvirt#5 0x000003ffb5cd2c84 in virDomainDefineXML libvirt#6 0x000000011745aa82 in remoteDispatchDomainDefineXML ... Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>

When only geteuid() is mocked, the test crashes on Debian 10. Fatal: failed to reset uid: No such file or directory Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) t a a bt Thread 1 (Thread 0x7ffff3b3e080 (LWP 12003)): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 libvirt#1 0x00007ffff7798535 in __GI_abort () at abort.c:79 libvirt#2 0x00007ffff485ca20 in _gcry_logv (level=level@entry=40, fmt=fmt@entry=0x7ffff4929126 "failed to reset uid: %s\n", arg_ptr=arg_ptr@entry=0x7fffffffe4a0) at ../../src/misc.c:142 libvirt#3 0x00007ffff485cd61 in _gcry_log_fatal (fmt=fmt@entry=0x7ffff4929126 "failed to reset uid: %s\n") at ../../src/misc.c:218 libvirt#4 0x00007ffff48639d1 in lock_pool_pages (n=<optimized out>, p=<optimized out>) at ../../src/secmem.c:340 libvirt#5 _gcry_secmem_init_internal (n=<optimized out>) at ../../src/secmem.c:563 libvirt#6 0x00007ffff4863d78 in _gcry_secmem_init (n=4096) at ../../src/secmem.c:581 libvirt#7 0x00007ffff485e4e6 in _gcry_vcontrol (cmd=<optimized out>, arg_ptr=arg_ptr@entry=0x7fffffffe5e0) at ../../src/global.c:506 libvirt#8 0x00007ffff485a789 in gcry_control (cmd=cmd@entry=GCRYCTL_INIT_SECMEM) at ../../src/visibility.c:79 libvirt#9 0x00007ffff71af10f in ssh_crypto_init () at ./src/libgcrypt.c:621 libvirt#10 0x00007ffff7193796 in _ssh_init (constructor=constructor@entry=1) at ./src/init.c:79 libvirt#11 0x00007ffff71834de in libssh_constructor () at ./src/init.c:116 libvirt#12 0x00007ffff7fe437a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe778, env=env@entry=0x7fffffffe788) at dl-init.c:72 libvirt#13 0x00007ffff7fe4476 in call_init (env=0x7fffffffe788, argv=0x7fffffffe778, argc=1, l=<optimized out>) at dl-init.c:30 libvirt#14 _dl_init (main_map=0x7ffff7ffe190, argc=1, argv=0x7fffffffe778, env=0x7fffffffe788) at dl-init.c:119 libvirt#15 0x00007ffff7fd60ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 libvirt#16 0x0000000000000001 in ?? () libvirt#17 0x00007fffffffea26 in ?? () libvirt#18 0x0000000000000000 in ?? () Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

If there's a list of mdevs to be assigned to a domain, but one of them (NOT the first) is already assigned to a different domain we're going to crash in the qemuProcessStop phase in virMediatedDeviceListFindIndex, because some of the pointers in mgr->activeMediatedHostdevs are dangling. This is due to virMediatedDeviceListMarkDevices using cleanup instead of rollback when we find out that a device is already taken. Reproducer steps: 1. start vm1 with mdev1 2. start vm2 with mdev2, mdev1 (the order is important!) Backtrace: #0 0x0000ffffb8c36250 in strcmp #1 0x0000ffffb9b80754 in virMediatedDeviceListFindIndex #2 0x0000ffffb9b80870 in virMediatedDeviceListFind #3 0x0000ffffb9c9e168 in virHostdevReAttachMediatedDevices #4 0x0000ffff9949f724 in qemuHostdevReAttachMediatedDevices #5 0x0000ffff9949f7f8 in qemuHostdevReAttachDomainDevices #6 0x0000ffff994bcd70 in qemuProcessStop #7 0x0000ffff994bf4e0 in qemuProcessStart Signed-off-by: Binfeng Wu <wubinfeng@huawei.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>

There is a race between vir_event_thread_finalize and virEventThreadWorker in releasing the last reference on the GMainContext. If virEventThreadDataFree() runs after vir_event_thread_finalize releases its reference, then it will release the last reference on the GMainContext. As a result g_autoptr cleanup on the GSource will access free'd memory. The race can be seen in non-deterministic crashes of the virt-run-qemu program during its shutdown, but could also likely affect the main libvirtd QEMU driver: Thread 2 (Thread 0x7f508ffff700 (LWP 222813)): #0 0x00007f509c8e26b0 in malloc_consolidate (av=av@entry=0x7f5088000020) at malloc.c:4488 #1 0x00007f509c8e4b08 in _int_malloc (av=av@entry=0x7f5088000020, bytes=bytes@entry=2048) at malloc.c:3711 #2 0x00007f509c8e6412 in __GI___libc_malloc (bytes=2048) at malloc.c:3073 #3 0x00007f509d6e925e in g_realloc (mem=0x0, n_bytes=2048) at gmem.c:164 #4 0x00007f509d705a57 in g_string_maybe_expand (string=string@entry=0x7f5088001f20, len=len@entry=1024) at gstring.c:102 #5 0x00007f509d705ab6 in g_string_sized_new (dfl_size=dfl_size@entry=1024) at gstring.c:127 #6 0x00007f509d708c5e in g_test_log_dump (len=<synthetic pointer>, msg=<synthetic pointer>) at gtestutils.c:3330 #7 0x00007f509d708c5e in g_test_log (lbit=G_TEST_LOG_ERROR, string1=0x7f508800fcb0 "GLib:ERROR:ghash.c:377:g_hash_table_lookup_node: assertion failed: (hash_table->ref_count > 0)", string2=<optimized out>, n_args=0, largs=0x0) at gtestutils.c:975 #8 0x00007f509d70af2a in g_assertion_message (domain=<optimized out>, file=0x7f509d7324a2 "ghash.c", line=<optimized out>, func=0x7f509d732750 <__func__.11348> "g_hash_table_lookup_node", message=<optimized out>) at gtestutils.c:2504 #9 0x00007f509d70af8e in g_assertion_message_expr (domain=domain@entry=0x7f509d72d76e "GLib", file=file@entry=0x7f509d7324a2 "ghash.c", line=line@entry=377, func=func@entry=0x7f509d732750 <__func__.11348> "g_hash_table_lookup_node", expr=expr@entry=0x7f509d732488 "hash_table->ref_count > 0") at gtestutils.c:2555 #10 0x00007f509d6d197e in g_hash_table_lookup_node (hash_table=0x55b70ace1760, key=<optimized out>, hash_return=<synthetic pointer>) at ghash.c:377 #11 0x00007f509d6d197e in g_hash_table_lookup_node (hash_return=<synthetic pointer>, key=<optimized out>, hash_table=0x55b70ace1760) at ghash.c:361 #12 0x00007f509d6d197e in g_hash_table_remove_internal (hash_table=0x55b70ace1760, key=<optimized out>, notify=1) at ghash.c:1371 #13 0x00007f509d6e0664 in g_source_unref_internal (source=0x7f5088000b60, context=0x55b70ad87e00, have_lock=0) at gmain.c:2103 #14 0x00007f509d6e1f64 in g_source_unref (source=<optimized out>) at gmain.c:2176 #15 0x00007f50a08ff84c in glib_autoptr_cleanup_GSource (_ptr=<synthetic pointer>) at /usr/include/glib-2.0/glib/glib-autocleanups.h:58 #16 0x00007f50a08ff84c in virEventThreadWorker (opaque=0x55b70ad87f80) at ../../src/util/vireventthread.c:114 #17 0x00007f509d70bd4a in g_thread_proxy (data=0x55b70acf3850) at gthread.c:784 #18 0x00007f509d04714a in start_thread (arg=<optimized out>) at pthread_create.c:479 #19 0x00007f509c95cf23 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f50a1380c00 (LWP 222802)): #0 0x00007f509c8977ff in __GI_raise (sig=sig@entry=6) a A377 t ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f509c881c35 in __GI_abort () at abort.c:79 #2 0x00007f509d72a823 in g_mutex_clear (mutex=0x55b70ad87e00) at gthread-posix.c:1307 #3 0x00007f509d72a823 in g_mutex_clear (mutex=mutex@entry=0x55b70ad87e00) at gthread-posix.c:1302 #4 0x00007f509d6e1a84 in g_main_context_unref (context=0x55b70ad87e00) at gmain.c:582 #5 0x00007f509d6e1a84 in g_main_context_unref (context=0x55b70ad87e00) at gmain.c:541 #6 0x00007f50a08ffabb in vir_event_thread_finalize (object=0x55b70ad83180 [virEventThread]) at ../../src/util/vireventthread.c:50 #7 0x00007f509d9c48a9 in g_object_unref (_object=<optimized out>) at gobject.c:3340 #8 0x00007f509d9c48a9 in g_object_unref (_object=0x55b70ad83180) at gobject.c:3232 #9 0x00007f509583d311 in qemuProcessQMPFree (proc=proc@entry=0x55b70ad87b90) at ../../src/qemu/qemu_process.c:8355 #10 0x00007f5095790f58 in virQEMUCapsInitQMPSingle (qemuCaps=qemuCaps@entry=0x55b70ad88010, libDir=libDir@entry=0x55b70ad049e0 "/tmp/virt-qemu-run-VZC9N0/lib/qemu", runUid=runUid@entry=107, runGid=runGid@entry=107, at ../../src/qemu/qemu_capabilities.c:5409 #11 0x00007f509579108f in virQEMUCapsInitQMP (runGid=107, runUid=107, libDir=0x55b70ad049e0 "/tmp/virt-qemu-run-VZC9N0/lib/qemu", qemuCaps=0x55b70ad88010) at ../../src/qemu/qemu_capabilities.c:5420 #12 0x00007f509579108f in virQEMUCapsNewForBinaryInternal (hostArch=VIR_ARCH_X86_64, binary=binary@entry=0x55b70ad7dc40 "/usr/libexec/qemu-kvm", libDir=0x55b70ad049e0 "/tmp/virt-qemu-run-VZC9N0/lib/qemu", runUid=107, runGid=107, hostCPUSignature=0x55b70ad01320 "GenuineIntel, Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz, family: 6, model: 85, stepping: 7", microcodeVersion=83898113, kernelVersion=0x55b70ad00d60 "4.18.0-211.el8.x86_64 #1 SMP Thu Jun 4 08:08:16 UTC 2020") at ../../src/qemu/qemu_capabilities.c:5472 #13 0x00007f5095791373 in virQEMUCapsNewData (binary=0x55b70ad7dc40 "/usr/libexec/qemu-kvm", privData=0x55b70ad5b8f0) at ../../src/qemu/qemu_capabilities.c:5505 #14 0x00007f50a09a32b1 in virFileCacheNewData (name=0x55b70ad7dc40 "/usr/libexec/qemu-kvm", cache=<optimized out>) at ../../src/util/virfilecache.c:208 #15 0x00007f50a09a32b1 in virFileCacheValidate (cache=cache@entry=0x55b70ad5c030, name=name@entry=0x55b70ad7dc40 "/usr/libexec/qemu-kvm", data=data@entry=0x7ffca39ffd90) at ../../src/util/virfilecache.c:277 #16 0x00007f50a09a37ea in virFileCacheLookup (cache=cache@entry=0x55b70ad5c030, name=name@entry=0x55b70ad7dc40 "/usr/libexec/qemu-kvm") at ../../src/util/virfilecache.c:310 #17 0x00007f5095791627 in virQEMUCapsCacheLookup (cache=0x55b70ad5c030, binary=0x55b70ad7dc40 "/usr/libexec/qemu-kvm") at ../../src/qemu/qemu_capabilities.c:5647 #18 0x00007f50957c34c3 in qemuDomainPostParseDataAlloc (def=<optimized out>, parseFlags=<optimized out>, opaque=<optimized out>, parseOpaque=0x7ffca39ffe18) at ../../src/qemu/qemu_domain.c:5470 #19 0x00007f50a0a34051 in virDomainDefPostParse (def=def@entry=0x55b70ad7d200, parseFlags=parseFlags@entry=258, xmlopt=xmlopt@entry=0x55b70ad5d010, parseOpaque=parseOpaque@entry=0x0) at ../../src/conf/domain_conf.c:5970 #20 0x00007f50a0a464bb in virDomainDefParseNode (xml=xml@entry=0x55b70aced140, root=root@entry=0x55b70ad5f020, xmlopt=xmlopt@entry=0x55b70ad5d010, parseOpaque=parseOpaque@entry=0x0, flags=flags@entry=258) at ../../src/conf/domain_conf.c:22520 #21 0x00007f50a0a4669b in virDomainDefParse (xmlStr=xmlStr@entry=0x55b70ad5f9e0 "<domain type='kvm'>\n <name>83</name>\n <uuid>9350639d-1c8a-4f51-a4a6-4eaf8eabe83e</uuid>\n <metadata>\n <libosinfo:libosinfo xmlns:libosinfo=\"http://libosinfo.org/xmlns/libvirt/domain/1.0\">\n <"..., filename=filename@entry=0x0, xmlopt=0x55b70ad5d010, parseOpaque=parseOpaque@entry=0x0, flags=flags@entry=258) at ../../src/conf/domain_conf.c:22474 #22 0x00007f50a0a467ae in virDomainDefParseString (xmlStr=xmlStr@entry=0x55b70ad5f9e0 "<domain type='kvm'>\n <name>83</name>\n <uuid>9350639d-1c8a-4f51-a4a6-4eaf8eabe83e</uuid>\n <metadata>\n <libosinfo:libosinfo xmlns:libosinfo=\"http://libosinfo.org/xmlns/libvirt/domain/1.0\">\n <"..., xmlopt=<optimized out>, parseOpaque=parseOpaque@entry=0x0, flags=flags@entry=258) at ../../src/conf/domain_conf.c:22488 #23 0x00007f50958ce112 in qemuDomainCreateXML (conn=0x55b70acf9090, xml=0x55b70ad5f9e0 "<domain type='kvm'>\n <name>83</name>\n <uuid>9350639d-1c8a-4f51-a4a6-4eaf8eabe83e</uuid>\n <metadata>\n <libosinfo:libosinfo xmlns:libosinfo=\"http://libosinfo.org/xmlns/libvirt/domain/1.0\">\n <"..., flags=0) at ../../src/qemu/qemu_driver.c:1744 #24 0x00007f50a0c268ac in virDomainCreateXML (conn=0x55b70acf9090, xmlDesc=0x55b70ad5f9e0 "<domain type='kvm'>\n <name>83</name>\n <uuid>9350639d-1c8a-4f51-a4a6-4eaf8eabe83e</uuid>\n <metadata>\n <libosinfo:libosinfo xmlns:libosinfo=\"http://libosinfo.org/xmlns/libvirt/domain/1.0\">\n <"..., flags=0) at ../../src/libvirt-domain.c:176 #25 0x000055b709547e7b in main (argc=<optimized out>, argv=<optimized out>) at ../../src/qemu/qemu_shim.c:289 The solution is to explicitly unref the GSource at a safe time instead of letting g_autoptr unref it when leaving scope. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Don't process subchannel devices where `def->driver` is not set. This fixes the following segfault: Thread 21 "nodedev-init" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x3ffb08fc910 (LWP 64303)] (gdb) bt #0 0x000003fffd1272b4 in __strcmp_vx () at /lib64/libc.so.6 #1 0x000003ffc260c3a8 in udevProcessCSS (device=0x3ff9018d130, def=0x3ff90194a90) #2 0x000003ffc260cb78 in udevGetDeviceDetails (device=0x3ff9018d130, def=0x3ff90194a90) #3 0x000003ffc260d126 in udevAddOneDevice (device=0x3ff9018d130) #4 0x000003ffc260d414 in udevProcessDeviceListEntry (udev=0x3ffa810d800, list_entry=0x3ff90001990) #5 0x000003ffc260d638 in udevEnumerateDevices (udev=0x3ffa810d800) #6 0x000003ffc260e08e in nodeStateInitializeEnumerate (opaque=0x3ffa810d800) #7 0x000003fffdaa14b6 in virThreadHelper (data=0x3ffa810df00) #8 0x000003fffc309ed6 in start_thread () #9 0x000003fffd185e66 in thread_start () (gdb) p *def $2 = { name = 0x0, sysfs_path = 0x3ff90198e80 "/sys/devices/css0/0.0.ff40", parent = 0x0, parent_sysfs_path = 0x0, parent_wwnn = 0x0, parent_wwpn = 0x0, parent_fabric_wwn = 0x0, driver = 0x0, devnode = 0x0, devlinks = 0x3ff90194670, caps = 0x3ff90194380 } Fixes: 05e6cda ("node_device: detect CSS devices") Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>

Commit f1b0890 introduced a potential crash due to incorrect operator precedence when accessing an element from a pointer to an array. Backtrace below: #0 virNodeDeviceGetMdevTypesCaps (sysfspath=0x7fff801661e0 "/sys/devices/pci0000:00/0000:00:02.0", mdev_types=0x7fff801c9b40, nmdev_types=0x7fff801c9b48) at ../src/conf/node_device_conf.c:2676 #1 0x00007ffff7caf53d in virNodeDeviceGetPCIDynamicCaps (sysfsPath=0x7fff801661e0 "/sys/devices/pci0000:00/0000:00:02.0", pci_dev=0x7fff801c9ac8) at ../src/conf/node_device_conf.c:2705 #2 0x00007ffff7cae38f in virNodeDeviceUpdateCaps (def=0x7fff80168a10) at ../src/conf/node_device_conf.c:2342 #3 0x00007ffff7cb11c0 in virNodeDeviceObjMatch (obj=0x7fff84002e50, flags=0) at ../src/conf/virnodedeviceobj.c:850 #4 0x00007ffff7cb153d in virNodeDeviceObjListExportCallback (payload=0x7fff84002e50, name=0x7fff801cbc20 "pci_0000_00_02_0", opaque=0x7fffe2ffc6a0) at ../src/conf/virnodedeviceobj.c:909 #5 0x00007ffff7b69146 in virHashForEach (table=0x7fff9814b700 = {...}, iter=0x7ffff7cb149e <virNodeDeviceObjListExportCallback>, opaque=0x7fffe2ffc6a0) at ../src/util/virhash.c:394 #6 0x00007ffff7cb1694 in virNodeDeviceObjListExport (conn=0x7fff98013170, devs=0x7fff98154430, devices=0x7fffe2ffc798, filter=0x7ffff7cf47a1 <virConnectListAllNodeDevicesCheckACL>, flags=0) at ../src/conf/virnodedeviceobj.c:943 #7 0x00007fffe00694b2 in nodeConnectListAllNodeDevices (conn=0x7fff98013170, devices=0x7fffe2ffc798, flags=0) at ../src/node_device/node_device_driver.c:228 #8 0x00007ffff7e703aa in virConnectListAllNodeDevices (conn=0x7fff98013170, devices=0x7fffe2ffc798, flags=0) at ../src/libvirt-nodedev.c:130 #9 0x000055555557f796 in remoteDispatchConnectListAllNodeDevices (server=0x555555627080, client=0x5555556bf050, msg=0x5555556c0000, rerr=0x7fffe2ffc8a0, args=0x7fffd4008470, ret=0x7fffd40084e0) at src/remote/remote_daemon_dispatch_stubs.h:1613 #10 0x000055555557f6f9 in remoteDispatchConnectListAllNodeDevicesHelper (server=0x555555627080, client=0x5555556bf050, msg=0x5555556c0000, rerr=0x7fffe2ffc8a0, args=0x7fffd4008470, ret=0x7fffd40084e0) at src/remote/remote_daemon_dispatch_stubs.h:1591 #11 0x00007ffff7ce9542 in virNetServerProgramDispatchCall (prog=0x555555690c10, server=0x555555627080, client=0x5555556bf050, msg=0x5555556c0000) at ../src/rpc/virnetserverprogram.c:428 #12 0x00007ffff7ce90bd in virNetServerProgramDispatch (prog=0x555555690c10, server=0x555555627080, client=0x5555556bf050, msg=0x5555556c0000) at ../src/rpc/virnetserverprogram.c:302 #13 0x00007ffff7cf042b in virNetServerProcessMsg (srv=0x555555627080, client=0x5555556bf050, prog=0x555555690c10, msg=0x5555556c0000) at ../src/rpc/virnetserver.c:137 #14 0x00007ffff7cf04eb in virNetServerHandleJob (jobOpaque=0x5555556b66b0, opaque=0x555555627080) at ../src/rpc/virnetserver.c:154 #15 0x00007ffff7bd912f in virThreadPoolWorker (opaque=0x55555562bc70) at ../src/util/virthreadpool.c:163 #16 0x00007ffff7bd8645 in virThreadHelper (data=0x55555562bc90) at ../src/util/virthread.c:233 #17 0x00007ffff6d90432 in start_thread () at /lib64/libpthread.so.0 #18 0x00007ffff75c5913 in clone () at /lib64/libc.so.6 Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>

Setting the system time backward would lead to a multiplication overflow in function virKeepAliveStart. The function virKeepAliveTimerInternal got the same bug too. Backtrace below: #0 0x0000ffffae898470 in raise () from /usr/lib64/libc.so.6 #1 0x0000ffffae89981c in abort () from /usr/lib64/libc.so.6 #2 0x0000ffffaf9a36a8 in __mulvsi3 () from /usr/lib64/libvirt.so.0 #3 0x0000ffffaf8fd9e8 in virKeepAliveStart (ka=0xaaaaf954ce10, interval=interval entry=0, count=count entry=0) at ../../src/rpc/virkeepalive.c:283 #4 0x0000ffffaf908560 in virNetServerClientStartKeepAlive (client=0xaaaaf954cbe0) at ../../src/rpc/virnetserverclient.c:1628 #5 0x0000aaaac57eb6dc in remoteDispatchConnectSupportsFeature (server=0xaaaaf95309d0, msg=0xaaaaf9549d90, ret=0xffff8c007fc0, args=0xffff8c002e70, rerr=0xffff9ea054a0, client=0xaaaaf954cbe0) at ../../src/remote/remote_daemon_dispatch.c:5063 #6 remoteDispatchConnectSupportsFeatureHelper (server=0xaaaaf95309d0, client=0xaaaaf954cbe0, msg=0xaaaaf9549d90, rerr=0xffff9ea054a0, args=0xffff8c002e70, ret=0xffff8c007fc0) at ./remote/remote_daemon_dispatch_stubs.h:3503 #7 0x0000ffffaf9053a4 in virNetServerProgramDispatchCall(msg=0xaaaaf9549d90, client=0xaaaaf954cbe0, server=0x0, prog=0xaaaaf953a170) at ../../src/rpc/virnetserverprogram.c:451 #8 virNetServerProgramDispatch (prog=0xaaaaf953a170, server=0x0, server entry=0xaaaaf95309d0, client=0xaaaaf954cbe0, msg=0xaaaaf9549d90) at ../../src/rpc/virnetserverprogram.c:306 #9 0x0000ffffaf90a6bc in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0xaaaaf95309d0) at ../../src/rpc/virnetserver.c:137 #10 virNetServerHandleJob (jobOpaque=0xaaaaf950df80, opaque=0xaaaaf95309d0) at ../../src/rpc/virnetserver.c:154 #11 0x0000ffffaf812e14 in virThreadPoolWorker (opaque=<optimized out>) at ../../src/util/virthreadpool.c:163 #12 0x0000ffffaf81237c in virThreadHelper (data=<optimized out>) at ../../src/util/virthread.c:246 #13 0x0000ffffaea327ac in ?? () from /usr/lib64/libpthread.so.0 #14 0x0000ffffae93747c in ?? () from /usr/lib64/libc.so.6 (gdb) frame 3 #3 0x0000ffffaf8fd9e8 in virKeepAliveStart (ka=0xaaaaf954ce10, interval=interval entry=0, count=count entry=0) at ../../src/rpc/virkeepalive.c:283 283 timeout = ka->interval - delay; (gdb) list 278 now = time(NULL); 279 delay = now - ka->lastPacketReceived; <='delay' got a negative value 280 if (delay > ka->interval) 281 timeout = 0; 282 else 283 timeout = ka->interval - delay; 284 ka->intervalStart = now - (ka->interval - timeout); 285 ka->timer = virEventAddTimeout(timeout * 1000, virKeepAliveTimer, <= multiplication overflow 286 ka, virObjectFreeCallback); 287 if (ka->timer < 0) (gdb) p now $2 = 18288001 (gdb) p ka->lastPacketReceived $3 = 1609430405 Signed-off-by: BiaoXiang Ye <yebiaoxiang@huawei.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>

…romBacking Commit bc3a78f errorneously removed the return value check from virStorageSourceNewFromBacking. In cases when we e.g. can't parse the backing store string this leads to a crash: #0 virStorageSourceGetActualType (def=0x0) at ../../../libvirt/src/conf/storage_source_conf.c:1014 #1 0x00007ffff7cee4f9 in virStorageSourceIsLocalStorage (src=<optimized out>) at ../../../libvirt/src/conf/storage_source_conf.c:1026 #2 0x00007ffff455c97c in storageBackendProbeTarget (encryption=0x7fff9c122ce8, target=0x7fff9c122c68) at ../../../libvirt/src/storage/storage_util.c:3443 #3 virStorageBackendRefreshVolTargetUpdate (v F438 ol=0x7fff9c122c30) at ../../../libvirt/src/storage/storage_util.c:3519 #4 0x00007ffff455cdc0 in virStorageBackendRefreshLocal (pool=0x7fff9c010ea0) at ../../../libvirt/src/storage/storage_util.c:3593 #5 0x00007ffff454f0a1 in storagePoolRefreshImpl (backend=backend@entry=0x7ffff4711180 <virStorageBackendDirectory>, obj=obj@entry=0x7fff9c010ea0, stateFile=stateFile@entry=0x7fff9c111a90 "/var/run/libvirt/storage/tmp.xml") at ../../../libvirt/src/storage/storage_driver.c:103 #6 0x00007ffff4550ea5 in storagePoolUpdateStateCallback (obj=0x7fff9c010ea0, opaque=<optimized out>) at ../../../libvirt/src/storage/storage_driver.c:165 #7 0x00007ffff7cefef4 in virStoragePoolObjListForEachCb (payload=<optimized out>, name=<optimized out>, opaque=0x7fffc8a489c0) at ../../../libvirt/src/conf/virstorageobj.c:435 #8 0x00007ffff7c03195 in virHashForEachSafe (table=<optimized out>, iter=iter@entry=0x7ffff7cefec0 <virStoragePoolObjListForEachCb>, opaque=opaque@entry=0x7fffc8a489c0) at ../../../libvirt/src/util/virhash.c:414 #9 0x00007ffff7cf0520 in virStoragePoolObjListForEach (pools=<optimized out>, iter=iter@entry=0x7ffff4550e10 <storagePoolUpdateStateCallback>, opaque=opaque@entry=0x0) at ../../../libvirt/src/conf/virstorageobj.c:468 #10 0x00007ffff454f43a in storagePoolUpdateAllState () at ../../../libvirt/src/storage/storage_driver.c:184 #11 storageStateInitialize (privileged=<optimized out>, root=<optimized out>, callback=<optimized out>, opaque=<optimized out>) at ../../../libvirt/src/storage/storage_driver.c:315 #12 0x00007ffff7e10c04 in virStateInitialize (opaque=0x555555621820, callback=0x55555557b1d0 <daemonInhibitCallback>, root=0x0, mandatory=<optimized out>, privileged=true) at ../../../libvirt/src/libvirt.c:656 #13 virStateInitialize (privileged=<optimized out>, mandatory=mandatory@entry=false, root=root@entry=0x0, callback=callback@entry=0x55555557b1d0 <daemonInhibitCallback>, opaque=opaque@entry=0x555555621820) at ../../../libvirt/src/libvirt.c:638 #14 0x000055555557b230 in daemonRunStateInit (opaque=0x555555621820) at ../../../libvirt/src/remote/remote_daemon.c:605 #15 0x00007ffff7c46bb5 in virThreadHelper (data=<optimized out>) at ../../../libvirt/src/util/virthread.c:233 #16 0x00007ffff6e453f9 in start_thread () at /lib64/libpthread.so.0 #17 0x00007ffff766fb53 in clone () at /lib64/libc.so An invalid image can be easily created by: $ qemu-img create -f qcow2 -F qcow2 -b 'json:{' -u img.qcow2 10M Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

…active If the VM isn't active calculating the job stats doesn't make sense. Additionally this prevents a crash of libvirtd if qemu terminates while libvirt wasn't running: Thread 28 "init-backup-tes" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb9310640 (LWP 3201116)] qemuDomainJobInfoUpdateTime (jobInfo=0x0) at ../../../libvirt/src/qemu/qemu_domainjob.c:275 275 if (!jobInfo->started) (gdb) bt #0 qemuDomainJobInfoUpdateTime (jobInfo=0x0) at ../../../libvirt/src/qemu/qemu_domainjob.c:275 #1 0x00007fffcba1a12d in qemuBackupJobTerminate (vm=0x7fff9c1bc840, jobstatus=QEMU_DOMAIN_JOB_STATUS_CANCELED) at ../../../libvirt/src/qemu/qemu_backup.c:563 #2 0x00007fffcbaefcae in qemuProcessStop (driver=0x7fff9c144ff0, vm=0x7fff9c1bc840, reason=VIR_DOMAIN_SHUTOFF_DAEMON, asyncJob=QEMU_ASYNC_JOB_NONE, flags=<optimized out>) at ../../../libvirt/src/qemu/qemu_process.c:7812 #3 0x00007fffcbaf2a10 in qemuProcessReconnect (opaque=<optimized out>) at ../../../libvirt/src/qemu/qemu_process.c:8578 #4 0x00007ffff7c46bb5 in virThreadHelper (data=<optimized out>) at ../../../libvirt/src/util/virthread.c:233 #5 0x00007ffff6e453f9 in start_thread () at /lib64/libpthread.so.0 #6 0x00007ffff766fb53 in clone () at /lib64/libc.so.6 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

If libvirtd is terminated before the node driver finishes initialization, it can crash with a backtrace similar to the following: Stack trace of thread 1922933: #0 0x00007f8515178774 g_hash_table_find (libglib-2.0.so.0) #1 0x00007f851593ea98 virHashSearch (libvirt.so.0) #2 0x00007f8515a1dd83 virNodeDeviceObjListSearch (libvirt.so.0) #3 0x00007f84cceb40a1 udevAddOneDevice (libvirt_driver_nodedev.so) #4 0x00007f84cceb5fae nodeStateInitializeEnumerate (libvirt_driver_nodedev.so) #5 0x00007f85159840cb virThreadHelper (libvirt.so.0) #6 0x00007f8511c7d14a start_thread (libpthread.so.0) #7 0x00007f851442bdb3 __clone (libc.so.6) Stack trace of thread 1922863: #0 0x00007f851442651d syscall (libc.so.6) #1 0x00007f85159842d4 virThreadSelfID (libvirt.so.0) #2 0x00007f851594e240 virLogFormatString (libvirt.so.0) #3 0x00007f851596635d vir_object_finalize (libvirt.so.0) #4 0x00007f8514efe8e9 g_object_unref (libgobject-2.0.so.0) #5 0x00007f85159667f8 virObjectUnref (libvirt.so.0) #6 0x00007f851517755f g_hash_table_remove_all_nodes.part.0 (libglib-2.0.so.0) #7 0x00007f8515177e62 g_hash_table_unref (libglib-2.0.so.0) #8 0x00007f851596637e vir_object_finalize (libvirt.so.0) #9 0x00007f8514efe8e9 g_object_unref (libgobject-2.0.so.0) #10 0x00007f85159667f8 virObjectUnref (libvirt.so.0) #11 0x00007f84cceb2b42 nodeStateCleanup (libvirt_driver_nodedev.so) #12 0x00007f8515b37950 virStateCleanup (libvirt.so.0) #13 0x00005648085348e8 main (libvirtd) #14 0x00007f8514352493 __libc_start_main (libc.so.6) #15 0x00005648085350fe _start (libvirtd) This is because the initial population of the device list is done in a separate initialization thread. If we attempt to exit libvirtd before this init thread has completed, we'll try to free the device list while accessing it from the other thread. In order to guarantee that this init thread is not accessing the device list when we're cleaning up the nodedev driver, make it joinable and wait for it to finish before proceding with the cleanup. This is similar to how we handle the udev event handler thread. The separate initialization thread was added in commit 9f0ae0b. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1836865 Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

libxl can deliver events and invoke callbacks on any application thread calling into libxl. This can cause deadlock in the libvirt libxl driver Thread 19 (Thread 0x7f31411ec700 (LWP 14068) "libvirtd"): #0 0x00007f318520cc7d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f3185205ed5 in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x00007f3189488015 in virMutexLock (m=<optimized out>) at ../../src/util/virthread.c:79 #3 0x00007f3189463f3b in virObjectLock (anyobj=<optimized out>) at ../../src/util/virobject.c:433 #4 0x00007f31894f2f41 in virDomainObjListSearchID (payload=0x7f317400a6d0, name=<optimized out>, data=0x7f31411eaeac) at ../../src/conf/virdomainobjlist.c:105 #5 0x00007f3189437ac5 in virHashSearch (ctable=0x7f3124025a30, iter=iter@entry=0x7f31894f2f30 <virDomainObjListSearchID>, data=data@entry=0x7f31411eaeac, name=name@entry=0x0) at ../../src/util/virhash.c:745 #6 0x00007f31894f3919 in virDomainObjListFindByID (doms=0x7f3124025430, id=<optimized out>) at ../../src/conf/virdomainobjlist.c:121 #7 0x00007f3152f292e5 in libxlDomainEventHandler (data=0x7f3124023d80, event=0x7f310c010ae0) at ../../src/libxl/libxl_domain.c:660 #8 0x00007f3152c6ff5d in egc_run_callbacks (egc=egc@entry=0x7f31411eaf50) at libxl_event.c:1427 #9 0x00007f3152c718bd in libxl__egc_cleanup (egc=0x7f31411eaf50) at libxl_event.c:1458 #10 libxl__ao_inprogress (ao=ao@entry=0x7f310c00b8a0, file=file@entry=0x7f3152cce987 "libxl_domain.c", line=line@entry=730, func=func@entry=0x7f3152ccf750 <__func__.22238> "libxl_domain_unpause") at libxl_event.c:2047 #11 0x00007f3152c8c5b8 in libxl_domain_unpause (ctx=0x7f3124015a40, domid=<optimized out>, ao_how=ao_how@entry=0x0) at libxl_domain.c:730 #12 0x00007f3152f2a584 in libxl_domain_unpause_0x041200 (domid=<optimized out>, ctx=<optimized out>) at /usr/include/libxl.h:1756 #13 libxlDomainStart (driver=driver@entry=0x7f3124023d80, vm=vm@entry=0x7f317400a6d0, start_paused=start_paused@entry=false, restore_fd=restore_fd@entry=-1, restore_ver=<optimized out>, restore_ver@entry=2) at ../../src/libxl/libxl_domain.c:1482 #14 0x00007f3152f2a6e3 in libxlDomainStartNew (driver=driver@entry=0x7f3124023d80, vm=vm@entry=0x7f317400a6d0, start_paused=start_paused@entry=false) at ../../src/libxl/libxl_domain.c:1545 #15 0x00007f3152f2a789 in libxlDomainShutdownHandleRestart (driver=0x7f3124023d80, vm=0x7f317400a6d0) at ../../src/libxl/libxl_domain.c:464 #16 0x00007f3152f2a9e4 in libxlDomainShutdownThread (opaque=<optimized out>) at ../../src/libxl/libxl_domain.c:559 #17 0x00007f3189487ee2 in virThreadHelper (data=<optimized out>) at ../../src/util/virthread.c:196 #18 0x00007f3185203539 in start_thread () from /lib64/libpthread.so.0 #19 0x00007f3184f3becf in clone () from /lib64/libc.so.6 Frame 16 runs a thread created to handle domain shutdown processing for domid 28712. In this case the event contained the reboot reason, so the old domain is destroyed and a new one is created by libxlDomainStart new. After starting the domain, it is unpaused by calling libxl_domain_unpause in frame 12. While the thread is running within libxl, libxl takes the opportunity to deliver a pending domain shutdown event for unrelated domid 28710. While searching for the associated virDomainObj by ID, a deadlock is encountered when attempting to lock the virDomainObj for domid 28712, which is already locked since this thread is processing its shutdown event. The deadlock can be avoided by moving the search for a virDomainObj associated with the event domid to the shutdown thread. The same is done for the death thread. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>

Commit 5adfb34 causes a segmentation fault. Stack trace of thread 664419: #0 0x000003ff62ec553c in qemuDomainUndefineFlags (dom=0x3ff6c002810, flags=<optimized out>) at ../src/qemu/qemu_driver.c:6618 #1 0x000003ff876a7e5c in virDomainUndefineFlags (domain=domain@entry=0x3ff6c002810, flags=<optimized out>) at ../src/libvirt-domain.c:6519 #2 0x000002aa2b64a808 in remoteDispatchDomainUndefineFlags (server=0x2aa2c3d7880, msg=0x2aa2c3d2770, args=<optimized out>, rerr=0x3ff8287b950, client=<optimized out>) at src/remote/remote_daemon_dispatch_stubs.h:13080 #3 remoteDispatchDomainUndefineFlagsHelper (server=0x2aa2c3d7880, client=<optimized out>, msg=0x2aa2c3d2770, rerr=0x3ff8287b950, args=<optimized out>, ret=0x0) at src/remote/remote_daemon_dispatch_stubs.h:13059 #4 0x000003ff8758bbf4 in virNetServerProgramDispatchCall (msg=0x2aa2c3d2770, client=0x2aa2c3e3050, server=0x2aa2c3d7880, prog=0x2aa2c3d8010) at ../src/rpc/virnetserverprogram.c:428 #5 virNetServerProgramDispatch (prog=0x2aa2c3d8010, server=server@entry=0x2aa2c3d7880, client=0x2aa2c3e3050, msg=0x2aa2c3d2770) at ../src/rpc/virnetserverprogram.c:302 #6 0x000003ff8758c260 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0x2aa2c3d7880) at ../src/rpc/virnetserver.c:140 #7 virNetServerHandleJob (jobOpaque=0x2aa2c3e2d30, opaque=0x2aa2c3d7880) at ../src/rpc/virnetserver.c:160 #8 0x000003ff874c49aa in virThreadPoolWorker (opaque=<optimized out>) at ../src/util/virthreadpool.c:164 #9 0x000003ff874c3f62 in virThreadHelper (data=<optimized out>) at ../src/util/virthread.c:256 #10 0x000003ff86c1cf8c in start_thread () from /lib64/libc.so.6 #11 0x000003ff86c9650e in thread_start () from /lib64/libc.so.6 Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

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=<optimized out>) 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=<optimized out>) 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 7cf76d4, the worker thread pool was freed before disposing any driver objects. Let's return to that pattern, but leave the other changes made by 7cf76d4. Signed-off-by: Tamara Schmitz <tamara.schmitz@suse.com> Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

Users are seeing periodic segfaults from libvirt client apps, especially thread heavy ones like virt-manager. A typical stack trace would end up in the virNetClientIOEventFD method, with illegal access to stale stack data. eg ==238721==ERROR: AddressSanitizer: stack-use-after-return on address 0x75cd18709788 at pc 0x75cd3111f907 bp 0x75cd181ff550 sp 0x75cd181ff548 WRITE of size 4 at 0x75cd18709788 thread T11 #0 0x75cd3111f906 in virNetClientIOEventFD /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:1634:15 libvirt#1 0x75cd3210d198 (/usr/lib/libglib-2.0.so.0+0x5a198) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2) libvirt#2 0x75cd3216c3be (/usr/lib/libglib-2.0.so.0+0xb93be) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2) libvirt#3 0x75cd3210ddc6 in g_main_loop_run (/usr/lib/libglib-2.0.so.0+0x5adc6) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2) libvirt#4 0x75cd3111a47c in virNetClientIOEventLoop /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:1722:9 libvirt#5 0x75cd3111a47c in virNetClientIO /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2002:10 libvirt#6 0x75cd3111a47c in virNetClientSendInternal /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2170:11 libvirt#7 0x75cd311198a8 in virNetClientSendWithReply /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2198:11 libvirt#8 0x75cd31111653 in virNetClientProgramCall /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclientprogram.c:318:9 libvirt#9 0x75cd31241c8f in callFull /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/remote/remote_driver.c:6054:10 libvirt#10 0x75cd31241c8f in call /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/remote/remote_driver.c:6076:12 libvirt#11 0x75cd31241c8f in remoteNetworkGetXMLDesc /usr/src/debug/libvirt/libvirt-10.2.0/build/src/remote/remote_client_bodies.h:5959:9 libvirt#12 0x75cd31410ff7 in virNetworkGetXMLDesc /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/libvirt-network.c:952:15 The root cause is a bad assumption in the virNetClientIOEventLoop method. This method is run by whichever thread currently owns the buck, and is responsible for handling I/O. Inside a for(;;) loop, this method creates a temporary GSource, adds it to the event loop and runs g_main_loop_run(). When I/O is ready, the GSource callback (virNetClientIOEventFD) will fire and call g_main_loop_quit(), and return G_SOURCE_REMOVE which results in the temporary GSource being destroyed. A g_autoptr() will then remove the last reference. What was overlooked, is that a second thread can come along and while it can't enter virNetClientIOEventLoop, it will register an idle source that uses virNetClientIOWakeup to interrupt the original thread's 'g_main_loop_run' call. When this happens the virNetClientIOEventFD callback never runs, and so the temporary GSource is not destroyed. The g_autoptr() will remove a reference, but by virtue of still being attached to the event context, there is an extra reference held causing GSource to be leaked. The next time 'g_main_loop_run' is called, the original GSource will trigger its callback, and access data that was allocated on the stack by the previous thread, and likely SEGV. To solve this, the thread calling 'g_main_loop_run' must call g_source_destroy, immediately upon return, to guarantee that the temporary GSource is removed. CVE-2024-4418 Reported-by: Martin Shirokov <shirokovmartin@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Message-Id: <20240502125431.3210288-1-berrange@redhat.com>

Users are seeing periodic segfaults from libvirt client apps, especially thread heavy ones like virt-manager. A typical stack trace would end up in the virNetClientIOEventFD method, with illegal access to stale stack data. eg ==238721==ERROR: AddressSanitizer: stack-use-after-return on address 0x75cd18709788 at pc 0x75cd3111f907 bp 0x75cd181ff550 sp 0x75cd181ff548 WRITE of size 4 at 0x75cd18709788 thread T11 #0 0x75cd3111f906 in virNetClientIOEventFD /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:1634:15 #1 0x75cd3210d198 (/usr/lib/libglib-2.0.so.0+0x5a198) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2) #2 0x75cd3216c3be (/usr/lib/libglib-2.0.so.0+0xb93be) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2) #3 0x75cd3210ddc6 in g_main_loop_run (/usr/lib/libglib-2.0.so.0+0x5adc6) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2) #4 0x75cd3111a47c in virNetClientIOEventLoop /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:1722:9 #5 0x75cd3111a47c in virNetClientIO /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2002:10 #6 0x75cd3111a47c in virNetClientSendInternal /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2170:11 #7 0x75cd311198a8 in virNetClientSendWithReply /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2198:11 #8 0x75cd31111653 in virNetClientProgramCall /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclientprogram.c:318:9 #9 0x75cd31241c8f in callFull /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/remote/remote_driver.c:6054:10 #10 0x75cd31241c8f in call /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/remote/remote_driver.c:6076:12 #11 0x75cd31241c8f in remoteNetworkGetXMLDesc /usr/src/debug/libvirt/libvirt-10.2.0/build/src/remote/remote_client_bodies.h:5959:9 #12 0x75cd31410ff7 in virNetworkGetXMLDesc /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/libvirt-network.c:952:15 The root cause is a bad assumption in the virNetClientIOEventLoop method. This method is run by whichever thread currently owns the buck, and is responsible for handling I/O. Inside a for(;;) loop, this method creates a temporary GSource, adds it to the event loop and runs g_main_loop_run(). When I/O is ready, the GSource callback (virNetClientIOEventFD) will fire and call g_main_loop_quit(), and return G_SOURCE_REMOVE which results in the temporary GSource being destroyed. A g_autoptr() will then remove the last reference. What was overlooked, is that a second thread can come along and while it can't enter virNetClientIOEventLoop, it will register an idle source that uses virNetClientIOWakeup to interrupt the original thread's 'g_main_loop_run' call. When this happens the virNetClientIOEventFD callback never runs, and so the temporary GSource is not destroyed. The g_autoptr() will remove a reference, but by virtue of still being attached to the event context, there is an extra reference held causing GSource to be leaked. The next time 'g_main_loop_run' is called, the original GSource will trigger its callback, and access data that was allocated on the stack by the previous thread, and likely SEGV. To solve this, the thread calling 'g_main_loop_run' must call g_source_destroy, immediately upon return, to guarantee that the temporary GSource is removed. CVE-2024-4418 Reviewed-by: Ján Tomko <jtomko@redhat.com> Reported-by: Martin Shirokov <shirokovmartin@gmail.com> Tested-by: Martin Shirokov <shirokovmartin@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

…kObjSetFwRemoval() The virNetworkObjSetFwRemoval() function is called at least two times when there's a network running and network driver initializes: 1) when loading state XMLs: #0 virNetworkObjSetFwRemoval (obj=0x7fffd4028250, fwRemoval=0x7fffd4020ad0) at ../src/conf/virnetworkobj.c:258 libvirt#1 0x00007ffff7a69c68 in virNetworkLoadState (...) at ../src/conf/virnetworkobj.c:952 libvirt#2 0x00007ffff7a6a35d in virNetworkObjLoadAllState (...) at ../src/conf/virnetworkobj.c:1072 libvirt#3 0x00007ffff7f9625f in networkStateInitialize (...) at ../src/network/bridge_driver.c:624 2) when firewall rules are being reloaded: #0 virNetworkObjSetFwRemoval (obj=0x7fffd4028250, fwRemoval=0x7fffd402e5b0) at ../src/conf/virnetworkobj.c:258 libvirt#1 0x00007ffff7f997b4 in networkReloadFirewallRulesHelper (obj=0x7fffd4028250, opaque=0x0) at ../src/network/bridge_driver.c:1703 libvirt#2 0x00007ffff7a6b09b in virNetworkObjListForEachHelper (payload=0x7fffd4028250, ...) at ../src/conf/virnetworkobj.c:1414 libvirt#3 0x00007ffff79287b6 in virHashForEachSafe (...) at ../src/util/virhash.c:387 libvirt#4 0x00007ffff7a6b119 in virNetworkObjListForEach (...) at ../src/conf/virnetworkobj.c:1441 libvirt#5 0x00007ffff7f99978 in networkReloadFirewallRules (...) at ../src/network/bridge_driver.c:1742 libvirt#6 0x00007ffff7f962f2 in networkStateInitialize (...) at ../src/network/bridge_driver.c:645 Since virNetworkObjSetFwRemoval() does not free the object stored in the first call, the second call just overwrites the stored pointer leading to a memory leak: 5,530 (48 direct, 5,482 indirect) bytes in 1 blocks are definitely lost in loss record 1,863 of 1,880 at 0x4848C43: calloc (vg_replace_malloc.c:1595) by 0x4F1E979: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.7800.6) by 0x4976E32: virFirewallNew (virfirewall.c:118) by 0x4979BA9: virFirewallParseXML (virfirewall.c:1071) by 0x4ABEB1E: virNetworkLoadState (virnetworkobj.c:938) by 0x4ABF35C: virNetworkObjLoadAllState (virnetworkobj.c:1072) by 0x4E9A25E: networkStateInitialize (bridge_driver.c:624) by 0x4CB1FA6: virStateInitialize (libvirt.c:665) by 0x15A6C6: daemonRunStateInit (remote_daemon.c:611) by 0x49E69F0: virThreadHelper (virthread.c:256) by 0x532B428: start_thread (in /lib64/libc.so.6) by 0x5397373: clone (in /lib64/libc.so.6) Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <1ff5099b2c15d328a178c4c7dec996c33f6e7a53.1718370189.git.mprivozn@redhat.com>

…kObjSetFwRemoval() The virNetworkObjSetFwRemoval() function is called at least two times when there's a network running and network driver initializes: 1) when loading state XMLs: #0 virNetworkObjSetFwRemoval (obj=0x7fffd4028250, fwRemoval=0x7fffd4020ad0) at ../src/conf/virnetworkobj.c:258 #1 0x00007ffff7a69c68 in virNetworkLoadState (...) at ../src/conf/virnetworkobj.c:952 #2 0x00007ffff7a6a35d in virNetworkObjLoadAllState (...) at ../src/conf/virnetworkobj.c:1072 #3 0x00007ffff7f9625f in networkStateInitialize (...) at ../src/network/bridge_driver.c:624 2) when firewall rules are being reloaded: #0 virNetworkObjSetFwRemoval (obj=0x7fffd4028250, fwRemoval=0x7fffd402e5b0) at ../src/conf/virnetworkobj.c:258 #1 0x00007ffff7f997b4 in networkReloadFirewallRulesHelper (obj=0x7fffd4028250, opaque=0x0) at ../src/network/bridge_driver.c:1703 #2 0x00007ffff7a6b09b in virNetworkObjListForEachHelper (payload=0x7fffd4028250, ...) at ../src/conf/virnetworkobj.c:1414 #3 0x00007ffff79287b6 in virHashForEachSafe (...) at ../src/util/virhash.c:387 #4 0x00007ffff7a6b119 in virNetworkObjListForEach (...) at ../src/conf/virnetworkobj.c:1441 #5 0x00007ffff7f99978 in networkReloadFirewallRules (...) at ../src/network/bridge_driver.c:1742 #6 0x00007ffff7f962f2 in networkStateInitialize (...) at ../src/network/bridge_driver.c:645 Since virNetworkObjSetFwRemoval() does not free the object stored in the first call, the second call just overwrites the stored pointer leading to a memory leak: 5,530 (48 direct, 5,482 indirect) bytes in 1 blocks are definitely lost in loss record 1,863 of 1,880 at 0x4848C43: calloc (vg_replace_malloc.c:1595) by 0x4F1E979: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.7800.6) by 0x4976E32: virFirewallNew (virfirewall.c:118) by 0x4979BA9: virFirewallParseXML (virfirewall.c:1071) by 0x4ABEB1E: virNetworkLoadState (virnetworkobj.c:938) by 0x4ABF35C: virNetworkObjLoadAllState (virnetworkobj.c:1072) by 0x4E9A25E: networkStateInitialize (bridge_driver.c:624) by 0x4CB1FA6: virStateInitialize (libvirt.c:665) by 0x15A6C6: daemonRunStateInit (remote_daemon.c:611) by 0x49E69F0: virThreadHelper (virthread.c:256) by 0x532B428: start_thread (in /lib64/libc.so.6) by 0x5397373: clone (in /lib64/libc.so.6) Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Variable 'master' needs to be free because it will be reassigned in virNetDevOpenvswitchInterfaceGetMaster(). The leaked stack: Direct leak of 11 byte(s) in 1 object(s) allocated from: #0 0x7f7dad8ba6df in __interceptor_malloc (/lib64/libasan.so.8+0xba6df) #1 0x7f7dad715728 in g_malloc (/lib64/libglib-2.0.so.0+0x60728) #2 0x7f7dad72d8b2 in g_strdup (/lib64/libglib-2.0.so.0+0x788b2) #3 0x7f7dacb63088 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321 #4 0x7f7dacb63088 in virNetDevGetName ../src/util/virnetdev.c:823 #5 0x7f7dacb63886 in virNetDevGetMaster ../src/util/virnetdev.c:909 #6 0x7f7dacb90288 in virNetDevTapReattachBridge ../src/util/virnetdevtap.c:527 #7 0x7f7dacd5cd67 in virDomainNetNotifyActualDevice ../src/conf/domain_conf.c:30505 #8 0x7f7da3a10bc3 in qemuProcessNotifyNets ../src/qemu/qemu_process.c:3290 #9 0x7f7da3a375c6 in qemuProcessReconnect ../src/qemu/qemu_process.c:9211 #10 0x7f7dacc0cc53 in virThreadHelper ../src/util/virthread.c:256 #11 0x7f7dac2875d4 in start_thread (/lib64/libc.so.6+0x875d4) #12 0x7f7dac3091bb in __GI___clone3 (/lib64/libc.so.6+0x1091bb) Fixes: de938b9 Signed-off-by: QiangWei Zhang <zhang.qiangwei@zte.com.cn> Reviewed-by: Peter Krempa <pkrempa@redhat.com>

…returning Successful return from 'virConnectDomainEventDeregisterAny' does not guarantee that there aren't still in-progress events being handled by the callbacks. Since 'cmdEvent' passes in a slice from an array as the private data of the callbacks, we must ensure that the array stays in scope (it's auto-freed) for the whole time there are possible callbacks being executed. While in practice this doesn't happen as the callbacks are usually quick enough to finish while unregistering stuff, placing a 'sleep(1)' into e.g. 'virshEventLifecyclePrint' and starting a domain results in crash of virsh with the following backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005557b5cfd343 in virshEventPrintf (data=data@entry=0x5557db9619b0, fmt=fmt@entry=0x5557b5d5e527 "%s") at ../../../libvirt/tools/virsh-domain-event.c:252 Thread 2 (Thread 0x7f59a54b7d00 (LWP 2097121)): #0 0x00007f59a6cadbf9 in __futex_abstimed_wait_common () at /lib64/libc.so.6 libvirt#1 0x00007f59a6cb2cf3 in __pthread_clockjoin_ex () at /lib64/libc.so.6 libvirt#2 0x00005557b5cd57f6 in virshDeinit (ctl=0x7ffc7b615140) at ../../../libvirt/tools/virsh.c:408 libvirt#3 0x00005557b5cd5391 in main (argc=<optimized out>, argv=<optimized out>) at ../../../libvirt/tools/virsh.c:932 Thread 1 (Thread 0x7f59a51a66c0 (LWP 2097122)): #0 0x00005557b5cfd343 in virshEventPrintf (data=data@entry=0x5557db9619b0, fmt=fmt@entry=0x5557b5d5e527 "%s") at ../../../libvirt/tools/virsh-domain-event.c:252 libvirt#1 0x00005557b5cffa10 in virshEventPrint (data=0x5557db9619b0, buf=0x7f59a51a55c0) at ../../../libvirt/tools/virsh-domain-event.c:290 libvirt#2 virshEventLifecyclePrint (conn=<optimized out>, dom=<optimized out>, event=<optimized out>, detail=<optimized out>, opaque=0x5557db9619b0) at ../../../libvirt/ [snipped] From the backtrace you can see that the 'main()' thread is already shutting down virsh, which means that 'cmdEvent' terminated and the private data was freed. The event loop thread is still execing the callback which accesses the data. To fix this add a condition and wait on all of the callbacks to be unregistered first (their private data freeing function will be called). This bug was observed when I've copied the event code for a new virsh command which had a bit more involved callbacks. Fixes: 99fa96c Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Message-Id: <9589d6d2a674173fcd53dec0aa0f6ab5decd55fc.1749110902.git.pkrempa@redhat.com>

…returning Successful return from 'virConnectDomainEventDeregisterAny' does not guarantee that there aren't still in-progress events being handled by the callbacks. Since 'cmdEvent' passes in a slice from an array as the private data of the callbacks, we must ensure that the array stays in scope (it's auto-freed) for the whole time there are possible callbacks being executed. While in practice this doesn't happen as the callbacks are usually quick enough to finish while unregistering stuff, placing a 'sleep(1)' into e.g. 'virshEventLifecyclePrint' and starting a domain results in crash of virsh with the following backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005557b5cfd343 in virshEventPrintf (data=data@entry=0x5557db9619b0, fmt=fmt@entry=0x5557b5d5e527 "%s") at ../../../libvirt/tools/virsh-domain-event.c:252 Thread 2 (Thread 0x7f59a54b7d00 (LWP 2097121)): #0 0x00007f59a6cadbf9 in __futex_abstimed_wait_common () at /lib64/libc.so.6 #1 0x00007f59a6cb2cf3 in __pthread_clockjoin_ex () at /lib64/libc.so.6 #2 0x00005557b5cd57f6 in virshDeinit (ctl=0x7ffc7b615140) at ../../../libvirt/tools/virsh.c:408 #3 0x00005557b5cd5391 in main (argc=<optimized out>, argv=<optimized out>) at ../../../libvirt/tools/virsh.c:932 Thread 1 (Thread 0x7f59a51a66c0 (LWP 2097122)): #0 0x00005557b5cfd343 in virshEventPrintf (data=data@entry=0x5557db9619b0, fmt=fmt@entry=0x5557b5d5e527 "%s") at ../../../libvirt/tools/virsh-domain-event.c:252 #1 0x00005557b5cffa10 in virshEventPrint (data=0x5557db9619b0, buf=0x7f59a51a55c0) at ../../../libvirt/tools/virsh-domain-event.c:290 #2 virshEventLifecyclePrint (conn=<optimized out>, dom=<optimized out>, event=<optimized out>, detail=<optimized out>, opaque=0x5557db9619b0) at ../../../libvirt/ [snipped] From the backtrace you can see that the 'main()' thread is already shutting down virsh, which means that 'cmdEvent' terminated and the private data was freed. The event loop thread is still execing the callback which accesses the data. To fix this add a condition and wait on all of the callbacks to be unregistered first (their private data freeing function will be called). This bug was observed when I've copied the event code for a new virsh command which had a bit more involved callbacks. Fixes: 99fa96c Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>

Add a flag to the saveFlags function, after saveFlags call the domain…

3bf7770

… is paused, then you can make disk snapshot manually.

liu-weifeng closed this Dec 23, 2015

Yaoxu19870920 mentioned this pull request May 16, 2018

Add check for mon->msg in qemuMonitorSend #9

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add a flag to the saveFlags function #3

Add a flag to the saveFlags function #3

Uh oh!

Uh oh!

Uh oh!

Add a flag to the saveFlags function #3

Add a flag to the saveFlags function #3

Uh oh!

Conversation

Uh oh!

Uh oh!