Bug 2046172

Summary:	Possible hang or crash of libvirtd/virtqemud when starting a VM and device mapper is not available
Product:	Red Hat Enterprise Linux 8	Reporter:	Peter Krempa <pkrempa>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
Status:	CLOSED ERRATA	QA Contact:	Meina Li <meili>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.4	CC:	chhu, hhan, jdenemar, lmen, virt-bugs, virt-maint, xuzhang
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-8.0.0-3.module+el8.6.0+14098+5bee65f4	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	2046170	Environment:
Last Closed:	2022-05-10 13:25:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2046170
Bug Blocks:

Description Peter Krempa 2022-01-26 10:39:40 UTC

+++ This bug was initially created as a clone of Bug #2046170 +++

Description of problem:
When starting a VM and device mapper is not available. (e.g. module is removed or libvirt is being used in a container that doesn't grant access to the device mapper control socket) libvirtd/virtqemud enters a code path where a uninitialized variable is dereferenced causing undefined behaviour. Until now I observed a case of nothing happening and two cases of hung/looping process, but a crash is theoretically possible too.

Version-Release number of selected component (if applicable):
>=libvirt-7.8

How reproducible:
Unknown, depends on stack layout. 

Steps to Reproduce:
1. Make device mapper inaccessible (remove kernel module, or remove /dev/mapper/control device node)
2. Try to start a VM with 3+ disks, with local file-based storage
3. look for the startup process getting stuck

Actual results:
libvirtd/virtqemud gets stuck or crashes

Expected results:


Additional info:
https://gitlab.com/libvirt/libvirt/-/issues/268

Fixed upstream by:

commit ddb2384f0c78a91c40d95afdbc7fe325e95ef2bc 
Author: Peter Krempa <pkrempa>
Date:   Tue Jan 25 17:49:00 2022 +0100

    qemuDomainSetupDisk: Initialize 'targetPaths'
    
    Compiler isn't able to see that 'virDevMapperGetTargets' in cases e.g.
    when the devmapper isn't available may not initialize the value in the
    pointer passed as the second argument.
    
    The usage 'qemuDomainSetupDisk' lead to an accidental infinite loop as
    previous calls apparently doctored the stack to a point where
    'g_slist_concat' would end up in an infinite loop trying to find the end
    of the list.
    
    Fixes: 6c49c2ee9fcb88de02cdc333f666a8e95d60a3b0
    Closes: https://gitlab.com/libvirt/libvirt/-/issues/268
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Andrea Bolognani <abologna>

v8.0.0-180-gddb2384f0c

Note that the patch adds a trivial NULL-initialization of a pointer, so even if it's not possible to reproduce the issue the fix is trivial and safe.

Comment 3 Meina Li 2022-02-07 09:54:48 UTC

Same with https://bugzilla.redhat.com/show_bug.cgi?id=2046170#c2:

Pre-verified Version:
libvirt-8.0.0-3.module+el8.6.0+14098+5bee65f4.x86_64
qemu-kvm-6.2.0-5.module+el8.6.0+14025+ca131e0a.x86_64

Pre-verified Steps:
1. Remove /dev/mapper/control.
# rm -rf /dev/mapper/control
2. Start a guest with three disks.
# virsh domblklist lmn
 Target   Source
-----------------------------------------------
 vda      /var/lib/libvirt/images/lmn.qcow2
 vdb      /var/lib/libvirt/images/test.qcow2
 vdc      /var/lib/libvirt/images/test1.qcow2
# virsh start lmn
Domain 'lmn' started    ---no hang
3. Check the libvirtd log.
2022-02-07 09:51:39.859+0000: 90320: debug : qemuProcessLaunch:7488 : QEMU vm=0x7faba43f6300 name=lmn running with pid=90456
2022-02-07 09:51:39.859+0000: 90320: debug : qemuProcessLaunch:7495 : Writing early domain status to disk
2022-02-07 09:51:39.859+0000: 90320: debug : qemuProcessLaunch:7499 : Waiting for handshake from child
2022-02-07 09:51:39.859+0000: 90320: debug : virCommandHandshakeWait:2852 : Wait for handshake on 43
2022-02-07 09:51:39.859+0000: 90320: debug : qemuProcessLaunch:7507 : Building domain mount namespace (if required)
2022-02-07 09:51:39.859+0000: 90320: debug : qemuDomainSetupAllDisks:296 : Setting up disks
2022-02-07 09:51:39.859+0000: 90320: debug : virDMOpen:141 : device mapper not available 
2022-02-07 09:51:39.859+0000: 90320: debug : virDMOpen:141 : device mapper not available
2022-02-07 09:51:39.859+0000: 90320: debug : virDMOpen:141 : device mapper not available
2022-02-07 09:51:39.859+0000: 90320: debug : qemuDomainSetupAllDisks:304 : Setup all disks

Comment 6 Meina Li 2022-02-10 07:45:51 UTC

Verified Version:
libvirt-8.0.0-3.module+el8.6.0+14098+5bee65f4.x86_64
qemu-kvm-6.2.0-6.module+el8.6.0+14165+5e5e76ac.x86_64

Verified Steps:
based on comment 3

Comment 8 errata-xmlrpc 2022-05-10 13:25:26 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:1759