Bug 1367130
| Summary: | USB address referencing a non-existent hub crashes libvirtd | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ján Tomko <jtomko> |
| Component: | libvirt | Assignee: | Ján Tomko <jtomko> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | dyuan, pzhang, rbalakri, xuzhang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-2.0.0-6.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-03 18:53:14 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: | |||
Fixed upstream by:
commit ef66bd5df8af93db5a77f0c1f33182139c9b63b3
Author: Ján Tomko <jtomko>
CommitDate: 2016-08-16 12:31:41 +0200
conf: report an error message for non-existing USB hubs
If any of the devices referenced a USB hub that does not exist,
defining the domain would either fail with:
error: An error occurred, but the cause is unknown
(if only the last hub in the path is missing)
or crash.
Return a proper error instead of crashing.
https://bugzilla.redhat.com/show_bug.cgi?id=1367130
git describe: v2.1.0-138-gef66bd5
I can reproduce this bug on libvirt-2.0.0-5.el7.x86_64
and verify it on libvirt-2.0.0-6.el7.x86_64
steps:
1. Preparing a xml like following, it has a usb redirect device plug on a
non-existing hub :
# cat vm3.xml | grep usb -A 3
<controller type='usb' index='0' model='nec-xhci'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
--
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='1'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='2.4.5'/>
</redirdev>
2. define a guest, it should report an error:
# virsh define vm3.xml
error: Failed to define domain from vm3.xml
error: XML error: there is no hub at port 2 in USB address bus: 0 port: 2.4.5
3. For a running guest, virsh edit to add a usb input devices which plugs on
a non-existing hub:
#virsh edit vm1
......
<input type='mouse' bus='usb'>
<address type='usb' bus='0' port='1.2.3'/>
</input>
......
save changes, it should report an error:
# virsh edit vm1
error: XML error: there is no hub at port 1 in USB address bus: 0 port: 1.2.3
Failed. Try again? [y,n,i,f,?]:
4. add a hub by manual, and plug a usb device on this hub, it should success.
#virsh edit vm1
......
<hub type='usb'>
<address type='usb' bus='0' port='6'/>
</hub>
<input type='mouse' bus='usb'>
<address type='usb' bus='0' port='6.1'/>
</input>
.....
save changes successfully.
restart guestm guest works well.
# virsh destroy vm1; virsh start vm1
Domain vm1 destroyed
Domain vm1 started
Now if hub is non-existing, it will report an error, libvirtd won't crash.
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 |
Description of problem: USB address referencing a non-existent hub crashes libvirt Version-Release number of selected component (if applicable): libvirt-2.0.0-5.el7.x86_64 How reproducible: 101.80 % Steps to Reproduce: 1. Define a domain referencing a non-existent hub: virsh -c qemu:///system define /dev/stdin <<EOF <domain type='kvm'> <name>test</name> <memory unit='GiB'>1</memory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc'>hvm</type> </os> <devices> <emulator>/usr/libexec/qemu</emulator> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1.2.3'/> </input> </devices> </domain> EOF Actual results: Libvirtd crashes: ==29659== Thread 11: ==29659== Invalid read of size 8 ==29659== at 0x5571508: virDomainUSBAddressFindPort (domain_addr.c:1532) ==29659== by 0x5571FA5: virDomainUSBAddressReserve (domain_addr.c:1779) ==29659== by 0x55A98AA: virDomainUSBDeviceDefForeach (domain_conf.c:24261) ==29659== by 0x2C7E8C: qemuDomainAssignUSBAddresses (qemu_domain_address.c:1732) ==29659== by 0x2C6F56: qemuDomainAssignAddresses (qemu_domain_address.c:1779) ==29659== by 0x2BA7C9: qemuDomainDefAssignAddresses (qemu_domain.c:2664) ==29659== by 0x557BE6E: virDomainDefPostParse (domain_conf.c:4493) ==29659== by 0x5594FC1: virDomainDefParseXML (domain_conf.c:17369) ==29659== by 0x558E554: virDomainDefParseNode (domain_conf.c:17551) ==29659== by 0x558E3E4: virDomainDefParse (domain_conf.c:17498) ==29659== by 0x558E335: virDomainDefParseString (domain_conf.c:17513) ==29659== by 0x1DA04B: qemuDomainDefineXMLFlags (qemu_driver.c:7153) ==29659== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==29659== ==29659== ==29659== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==29659== Access not within mapped region at address 0x8 ==29659== at 0x5571508: virDomainUSBAddressFindPort (domain_addr.c:1532) ==29659== by 0x5571FA5: virDomainUSBAddressReserve (domain_addr.c:1779) ==29659== by 0x55A98AA: virDomainUSBDeviceDefForeach (domain_conf.c:24261) ==29659== by 0x2C7E8C: qemuDomainAssignUSBAddresses (qemu_domain_address.c:1732) ==29659== by 0x2C6F56: qemuDomainAssignAddresses (qemu_domain_address.c:1779) ==29659== by 0x2BA7C9: qemuDomainDefAssignAddresses (qemu_domain.c:2664) ==29659== by 0x557BE6E: virDomainDefPostParse (domain_conf.c:4493) ==29659== by 0x5594FC1: virDomainDefParseXML (domain_conf.c:17369) ==29659== by 0x558E554: virDomainDefParseNode (domain_conf.c:17551) ==29659== by 0x558E3E4: virDomainDefParse (domain_conf.c:17498) ==29659== by 0x558E335: virDomainDefParseString (domain_conf.c:17513) ==29659== by 0x1DA04B: qemuDomainDefineXMLFlags (qemu_driver.c:7153) ==29659== If you believe this happened as a result of a stack ==29659== overflow in your program's main thread (unlikely but ==29659== possible), you can try to increase the size of the ==29659== main thread stack using the --main-stacksize= flag. ==29659== The main thread stack size used in this run was 8388608. Expected results: No crash.