Red Hat Bugzilla – Bug 1367259
libvirt SIGSEGV when hot-plug a disk with luks encryption
Last modified: 2016-11-03 14:53:19 EDT
Created attachment 1191062 [details] gdb backtrace Description of problem: As subject Version-Release number of selected component (if applicable): 100% How reproducible: libvirt-2.0.0-5.el7.x86_64 qemu-kvm-rhev-2.6.0-20.el7.x86_64 Steps to Reproduce: 1. Prepare a secret and set its value as luks passphase # virsh secret-list UUID Usage -------------------------------------------------------------------------------- 579d8658-a7ed-4252-aba7-6cd0229a2c0d volume /var/lib/libvirt/images/luks.qcow2' # virsh secret-dumpxml 579d8658-a7ed-4252-aba7-6cd0229a2c0d <secret ephemeral='no' private='no'> <uuid>579d8658-a7ed-4252-aba7-6cd0229a2c0d</uuid> <description>LUKS</description> <usage type='volume'> <volume>/var/lib/libvirt/images/luks.qcow2</volume> </usage> </secret> # virsh secret-set-value 579d8658-a7ed-4252-aba7-6cd0229a2c0d --base64 $(echo redhat|base64) Secret value set 2. Create a luks volume using the secret # cat /tmp/luks-vol.xml <volume> <name>L</name> <key>/var/lib/libvirt/images/L</key> <source> </source> <capacity unit="G">5</capacity> <target> <path>/var/lib/libvirt/images/L</path> <format type='raw'/> <permissions> <mode>0644</mode> <owner>0</owner> <group>0</group> <label>unconfined_u:object_r:virt_image_t:s0</label> </permissions> <encryption format='luks'> <secret type='passphrase' uuid='579d8658-a7ed-4252-aba7-6cd0229a2c0d'/> </encryption> </target> </volume> # virsh vol-create default /tmp/luks-vol.xml Vol L created from /tmp/luks-vol.xml 3. Start a VM and attach the luks volume # virsh list Id Name State ---------------------------------------------------- 10 V running # cat /tmp/luks-disk-bug.xml <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/L'/> <target dev='vdb' bus='virtio'/> <encryption format='luks'> <secret type='passphrase' uuid='579d8658-a7ed-4252-aba7-6cd0229a2c0d'/> </encryption> </disk> # virsh attach-device V /tmp/luks-disk-bug.xml error: Disconnected from qemu:///system due to I/O error error: Failed to attach device from /tmp/luks-disk-bug.xml error: End of file while reading data: Input/output error # abrt-cli list --since 1471322614 id ad9c3b723ee5498366a419040898dbf59409eeca reason: libvirtd killed by SIGSEGV time: Tue 16 Aug 2016 01:15:51 PM CST cmdline: /usr/sbin/libvirtd --listen package: libvirt-daemon-2.0.0-5.el7 uid: 0 (root) Directory: /var/spool/abrt/ccpp-2016-08-16-01:15:51-19710 Run 'abrt-cli report /var/spool/abrt/ccpp-2016-08-16-01:15:51-19710' for creating a case in Red Hat Customer Portal Actual results: As step3 Expected results: no SIGSEGV Additional info:
Good catch - this one was a result of changes made after the initial luks support was added. More details are in the patch which is posted upstream: http://www.redhat.com/archives/libvir-list/2016-August/msg00805.html
Adjusted the commit based on review comment see: http://www.redhat.com/archives/libvir-list/2016-August/msg00867.html pushed change: commit b4478c16c02f28d88673709947124c6ea2fb4c7b Author: John Ferlan <jferlan@redhat.com> Date: Wed Aug 17 10:25:43 2016 -0400 qemu: Fix crash hot plugging luks volume ... Crash occurs because 'secrets' is being dereferenced in call: if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias, VIR_SECRET_USAGE_TYPE_VOLUME, NULL, &src->encryption->secrets[0]->seclookupdef, true) < 0) ... git describe b4478c16c02f28d88673709947124c6ea2fb4c7b v2.1.0-169-gb4478c1
I can reproduce it with libvirt-2.0.0-5.el7.x86_64 Verify version : libvirt-2.0.0-8.el7.x86_64 qemu-kvm-rhev-2.6.0-24.el7.x86_64 Verify steps : 1. Prepare a swcret as following # virsh secret-list UUID Usage -------------------------------------------------------------------------------- f981dd17-1234-45bc-88e6-ed1fe20ce9da volume /var/lib/libvirt/images/luks/luks1.img 2. Prepare a luks pool and create a volume in the pool # virsh vol-list luks-pool Name Path ------------------------------------------------------------------------------ luks /var/lib/libvirt/images/luks/luks luks1.img /var/lib/libvirt/images/luks/luks1.img # virsh vol-dumpxml luks luks-pool <volume type='file'> <name>luks</name> <key>/var/lib/libvirt/images/luks/luks</key> <source> </source> <capacity unit='bytes'>1074270208</capacity> <allocation unit='bytes'>69632</allocation> <target> <path>/var/lib/libvirt/images/luks/luks</path> <format type='raw'/> <permissions> <mode>0600</mode> <owner>107</owner> <group>107</group> <label>system_u:object_r:svirt_image_t:s0:c300,c387</label> </permissions> <timestamps> <atime>1473648746.592287230</atime> <mtime>1473647292.637084255</mtime> <ctime>1473648746.152262947</ctime> </timestamps> <encryption format='luks'> </encryption> </target> </volume> 3. define and start a guest # virsh list Id Name State ---------------------------------------------------- 2 vm1 running using the luks volume as the source of virtual disk # cat file-disk.xml <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/luks/luks'/> <target dev='vdb' bus='virtio'/> <encryption format='luks'> <secret type='passphrase' uuid='f981dd17-1234-45bc-88e6-ed1fe20ce9da'/> </encryption> </disk> attach this disk to guest, it should attach successfully. # virsh attach-device vm1 file-disk.xml Device attached successfully dumpxml to check # virsh dumpxml vm1 | grep disk -A 9 ...... <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/luks/luks'/> <backingStore/> <target dev='vdb' bus='virtio'/> <encryption format='luks'> <secret type='passphrase' uuid='f981dd17-1234-45bc-88e6-ed1fe20ce9da'/> </encryption> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> login guest to check #lsblk it will list the disk # virsh detach-device vm1 file-disk.xml Device detached successfully No SIGSEGV now, it can attach successfully. Move to verified.
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, 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://rhn.redhat.com/errata/RHSA-2016-2577.html