Red Hat Bugzilla – Bug 845523
Use after free when escaping sequence for console
Last modified: 2013-02-21 02:20:57 EST
Description of problem: Valgrind complains use after free issue when escaping sequence for console. Version-Release number of selected component (if applicable): # rpm -q libvirt libvirt-0.10.0-0rc0.el6.x86_64 How reproducible: always Steps to Reproduce: 1. valgrind -v --leak-check=full virsh console <domain> 2. ctrl+] 3. Actual results: ==16663== 1 errors in context 1 of 2: ==16663== Invalid read of size 4 ==16663== at 0x4D04C3F: virStreamFree (libvirt.c:15347) ==16663== by 0x40B121: vshRunConsole (console.c:404) ==16663== by 0x420E0E: cmdRunConsole (virsh-domain.c:1658) ==16663== by 0x4211BE: cmdConsole (virsh-domain.c:1693) ==16663== by 0x41B574: vshCommandRun (virsh.c:1877) ==16663== by 0x42D476: main (virsh.c:3282) ==16663== Address 0x52bb980 is 0 bytes inside a block of size 40 free'd ==16663== at 0x4A0595D: free (vg_replace_malloc.c:366) ==16663== by 0x4C7B418: virFree (memory.c:309) ==16663== by 0x4CEC39B: virUnrefStream (datatypes.c:1084) ==16663== by 0x4D04C5F: virStreamFree (libvirt.c:15355) ==16663== by 0x40A8C0: virConsoleShutdown (console.c:103) ==16663== by 0x4C7459E: virEventPollRunOnce (event_poll.c:485) ==16663== by 0x4C73346: virEventRunDefaultImpl (event.c:247) ==16663== by 0x42A901: vshEventLoop (virsh.c:2416) ==16663== by 0x4C849A8: virThreadHelper (threads-pthread.c:161) ==16663== by 0x38BAA077F0: start_thread (pthread_create.c:301) ==16663== by 0x33F68E570C: clone (clone.S:115) Expected results: fix it. Additional info: # virsh dumpxml foo # virsh dumpxml foo <domain type='qemu' id='1'> <name>foo</name> <uuid>595958e9-0a1e-e406-6b9e-0e85cfdbaf3d</uuid> <memory unit='KiB'>220160</memory> <currentMemory unit='KiB'>220160</currentMemory> <vcpu placement='static'>4</vcpu> <os> <type arch='x86_64' machine='rhel6.3.0'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/foo'/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </disk> <controller type='usb' index='0'> <alias name='usb0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='ide' index='0'> <alias name='ide0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <serial type='pty'> <source path='/dev/pts/6'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/6'> <source path='/dev/pts/6'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='spice' port='5901' autoport='yes' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='cirrus' vram='9216' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c220,c851</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c220,c851</imagelabel> </seclabel> </domain>
Fixed upstream: commit e3b8808ba764e06f68785a2bbdd8b7ab00b71fa4 Author: Peter Krempa <pkrempa@redhat.com> Date: Fri Aug 3 13:16:24 2012 +0200 virsh: console: Avoid using stream after being freed. The stream object wasn't set to NULL after freeing causing a double free attempt on the cleanup path. Moving to POST.
can reproduce this with libvirt-0.10.0-0rc0.el6.x86_64 verify with libvirt-0.10.0-0rc1.el6.x86_64 step : 1. valgrind -v --leak-check=full virsh console <domain> 2. ctrl+] not found use after free error, no memeory leak, verification passed.
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. http://rhn.redhat.com/errata/RHSA-2013-0276.html