Bug 1056328

Summary: Segfault in qemuDiskGetActualType
Product: [Community] Virtualization Tools Reporter: Kevin Shanahan <kevin>
Component: libvirtAssignee: Peter Krempa <pkrempa>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, pkrempa
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-22 10:43:58 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:
Attachments:
Description Flags
Domain XML file which crashes libvirtd none

Description Kevin Shanahan 2014-01-22 01:44:53 UTC
Description of problem:

I'm getting a crash in qemuDiskGetActualType with one of my VMs (will attach the domain xml).  It seems that def->srcpool is null and the dereference on line 1303 of qemu/qemu_conf.c is causing the crash.

Version-Release number of selected component (if applicable):

1.2.1

How reproducible:

Always.

Steps to Reproduce:
1. virsh start win7 (Domain XML attached)

Actual results:

# virsh start win7
error: Failed to start domain win7
error: End of file while reading data: Input/output error
error: Failed to reconnect to the hypervisor


Expected results:

Not crashing ;-)


Additional info:

gdb backtrace:

#0  0x00007f31feb601cb in qemuDiskGetActualType (def=0x7f31f80b9ce0)
    at qemu/qemu_conf.c:1306
#1  0x00007f31feb2606c in qemuBuildDriveStr (conn=0x7f31e8000a80, 
    disk=0x7f31f80b9ce0, bootable=false, qemuCaps=0x7f31e400b800)
    at qemu/qemu_command.c:3930
#2  0x00007f31feb3380d in qemuBuildCommandLine (conn=0x7f31e8000a80, 
    driver=0x7f31f8017050, def=0x7f31f80cdfe0, monitor_chr=0x7f31e4002360, 
    monitor_json=true, qemuCaps=0x7f31e400b800, migrateFrom=0x0, migrateFd=-1, 
    snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, 
    callbacks=0x7f31fee1a8e8 <buildCommandLineCallbacks>)
    at qemu/qemu_command.c:8498
#3  0x00007f31feb6af35 in qemuProcessStart (conn=0x7f31e8000a80, 
    driver=0x7f31f8017050, vm=0x7f31f80c5230, migrateFrom=0x0, stdin_fd=-1, 
    stdin_path=0x0, snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, 
    flags=1) at qemu/qemu_process.c:3851
#4  0x00007f31febb227f in qemuDomainObjStart (conn=0x7f31e8000a80, 
    driver=0x7f31f8017050, vm=0x7f31f80c5230, flags=0)
    at qemu/qemu_driver.c:6065
#5  0x00007f31febb2506 in qemuDomainCreateWithFlags (dom=0x7f31e40008c0, 
    flags=0) at qemu/qemu_driver.c:6117
#6  0x00007f31febb2595 in qemuDomainCreate (dom=0x7f31e40008c0)
    at qemu/qemu_driver.c:6135
#7  0x00007f320c5ca868 in virDomainCreate (domain=0x7f31e40008c0)
    at libvirt.c:8831
#8  0x00007f320d0aef40 in remoteDispatchDomainCreate (server=0x7f320f060870, 
    client=0x7f320f06dc80, msg=0x7f320f06fbb0, rerr=0x7f32057bbbf0, 
    args=0x7f31e4000900) at remote_dispatch.h:2953
#9  0x00007f320d0aee2d in remoteDispatchDomainCreateHelper (
    server=0x7f320f060870, client=0x7f320f06dc80, msg=0x7f320f06fbb0, 
    rerr=0x7f32057bbbf0, args=0x7f31e4000900, ret=0x7f31e40009a0)
    at remote_dispatch.h:2931
#10 0x00007f320c649acf in virNetServerProgramDispatchCall (
    prog=0x7f320f068140, server=0x7f320f060870, client=0x7f320f06dc80, 
    msg=0x7f320f06fbb0) at rpc/virnetserverprogram.c:435
#11 0x00007f320c64962e in virNetServerProgramDispatch (prog=0x7f320f068140, 
    server=0x7f320f060870, client=0x7f320f06dc80, msg=0x7f320f06fbb0)
    at rpc/virnetserverprogram.c:305
#12 0x00007f320c640d67 in virNetServerProcessMsg (srv=0x7f320f060870, 
    client=0x7f320f06dc80, prog=0x7f320f068140, msg=0x7f320f06fbb0)
    at rpc/virnetserver.c:165
#13 0x00007f320c640e4b in virNetServerHandleJob (jobOpaque=0x7f320f06f700, 
    opaque=0x7f320f060870) at rpc/virnetserver.c:186
#14 0x00007f320c50a89a in virThreadPoolWorker (opaque=0x7f320f060610)
    at util/virthreadpool.c:144
#15 0x00007f320c50a228 in virThreadHelper (data=0x7f320f0605a0)
    at util/virthreadpthread.c:161
#16 0x00007f3209fc00a2 in start_thread () from /usr/lib/libpthread.so.0
#17 0x00007f320939b32d in clone () from /usr/lib/libc.so.6

Comment 1 Kevin Shanahan 2014-01-22 01:47:27 UTC
Created attachment 853552 [details]
Domain XML file which crashes libvirtd

Note that libvirt 1.2.0 does not crash with this same config.

Comment 2 Peter Krempa 2014-01-22 10:43:58 UTC
Fixed upstream:

commit 7f0fd427413fe04963b1bcb158cf70e980ad1842
Author: Peter Krempa <pkrempa>
Date:   Wed Jan 22 10:27:52 2014 +0100

    qemu: Avoid crash in qemuDiskGetActualType
    
    Libvirtd would crash if a domain contained an empty cdrom drive of
    type='volume' as the disk def->srcpool member would be dereferenced. Fix
    it by checking if the source pool is present before dereferencing it.
    
    Also alter tests to catch this issue in the future.
    
    Reported by: Kevin Shanahan
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1056328