Bug 679164 - memory bugs in libvirt
Summary: memory bugs in libvirt
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 656795
Blocks: 682249
TreeView+ depends on / blocked
 
Reported: 2011-02-21 19:23 UTC by Eric Blake
Modified: 2011-05-19 13:28 UTC (History)
9 users (show)

Fixed In Version: libvirt-0.8.7-8.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 682249 (view as bug list)
Environment:
Last Closed: 2011-05-19 13:28:09 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0596 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-05-18 17:56:36 UTC

Description Eric Blake 2011-02-21 19:23:51 UTC
Description of problem:
valgrind reports the use of uninitialized memory affecting libvirtd execution, as well as several leaks directly attributable to libvirt

Version-Release number of selected component (if applicable):
libvirt-0.8.7-7.el6

How reproducible:
100%

Steps to Reproduce:
1. service libvirtd stop
2. valgrind --leak-check=full /usr/sbin/libvirtd&
3. sleep 30 && kill $!
  
Actual results:
Output includes:
==29158== Conditional jump or move depends on uninitialised value(s)
==29158==    at 0x3297C43DF5: _itoa_word (in /lib64/libc-2.12.so)
==29158==    by 0x3297C44EB4: vfprintf (in /lib64/libc-2.12.so)
==29158==    by 0x3297C6EFF1: vsnprintf (in /lib64/libc-2.12.so)
==29158==    by 0x3297C4F062: snprintf (in /lib64/libc-2.12.so)
==29158==    by 0x3297D099E5: getnameinfo (in /lib64/libc-2.12.so)
==29158==    by 0x3C9AE3D975: virSocketFormatAddrFull (network.c:194)

fixed by upstream:
commit 243b7814c778e555e63d105dac049291475221dc
Author: Eric Blake <eblake@redhat.com>
Date:   Mon Jan 10 15:08:56 2011 -0700

    network: plug unininitialized read found by valgrind
    
    * src/util/network.c (virSocketAddrMask): Zero out port, so that
    iptables can initialize just the netmask then call
    virSocketFormatAddr without an uninitialized read in getnameinfo.


It also includes:
==29158== 8 bytes in 1 blocks are definitely lost in loss record 53 of 413
==29158==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==29158==    by 0x3C9AE3983B: virAllocN (memory.c:130)
==29158==    by 0x3C9AE467B6: virXPathNodeSet (xml.c:614)
==29158==    by 0x3C9AE630C7: virNetworkDefParseNode (network_conf.c:631)

fixed by upstream:
commit 6e2bab80c8899cee33d2958ee50e6f6fa304591f
Author: Eric Blake <eblake@redhat.com>
Date:   Mon Jan 10 15:35:37 2011 -0700

    network: plug memory leak
    
    * src/conf/network_conf.c (virNetworkDefParseXML): Release ipNodes.

It also includes:
==29158== 352 bytes in 11 blocks are definitely lost in loss record 374 of 413
==29158==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==29158==    by 0x3C9AE3985D: virAlloc (memory.c:102)
==29158==    by 0x3C9AE751E1: x86ModelNew (cpu_x86.c:744)
==29158==    by 0x3C9AE75AA4: x86MapLoadCallback (cpu_x86.c:943)

fixed by upstream:
commit fae1b8aac47ea5009b11f5d562e1eaa0ec925c6a
Author: Eric Blake <eblake@redhat.com>
Date:   Mon Jan 10 16:56:36 2011 -0700

    cpu: plug memory leak
    
    * src/cpu/cpu_x86.c (x86ModelLoad): Free data before overwriting.


Expected results:
The problems mentioned above should not appear in output (valgrind might detect other problems; for example, bug 620345 covers leaks related to libnl)

Additional info:

Comment 1 Eric Blake 2011-02-21 19:36:02 UTC
In POST, unless I find more to add to the list between now and the next libvirt build:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-February/msg01226.html

Comment 2 Eric Blake 2011-02-22 18:07:11 UTC
Another upstream memory corruption issue was pointed out, where an off-by-one can lead to malloc crashes depending on the length of $CWD:

https://www.redhat.com/archives/libvir-list/2011-February/msg01003.html

Comment 3 Eric Blake 2011-02-24 22:13:01 UTC
(In reply to comment #2)
> Another upstream memory corruption issue was pointed out, where an off-by-one
> can lead to malloc crashes depending on the length of $CWD:
> 
> https://www.redhat.com/archives/libvir-list/2011-February/msg01003.html

That issue is being tracked separately in bug 680281

Comment 5 Wayne Sun 2011-02-25 03:47:12 UTC
Verified
No memory leaks now. Also without possibly lost problems with libnl-1.1-13. 

Packages:
libvirt-0.8.7-8.el6.x86_64
valgrind-3.6.0-3.el6.x86_64
qemu-kvm-0.12.1.2-2.143.el6.x86_64
kernel-2.6.32-118.el6.x86_64
libnl-1.1-13.el6.x86_64


Steps:
1. service libvirtd stop
2. valgrind --leak-check=full /usr/sbin/libvirtd&
3. sleep 30 && kill $!

Actual results:
==9370== HEAP SUMMARY:
==9370==     in use at exit: 485,193 bytes in 7,167 blocks
==9370==   total heap usage: 82,835 allocs, 75,668 frees, 364,022,509 bytes allocated
==9370== 
==9370== LEAK SUMMARY:
==9370==    definitely lost: 0 bytes in 0 blocks
==9370==    indirectly lost: 0 bytes in 0 blocks
==9370==      possibly lost: 0 bytes in 0 blocks
==9370==    still reachable: 485,193 bytes in 7,167 blocks
==9370==         suppressed: 0 bytes in 0 blocks
==9370== Reachable blocks (those to which a pointer was found) are not shown.
==9370== To see them, rerun with: --leak-check=full --show-reachable=yes
==9370== 
==9370== For counts of detected and suppressed errors, rerun with: -v
==9370== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 30 from 9)

[1]+  Done                    valgrind --leak-check=full /usr/sbin/libvirtd

Comment 6 Wayne Sun 2011-02-25 03:54:06 UTC
FYI, the build is:
RHEL6.1-20110202.n.0

Comment 9 errata-xmlrpc 2011-05-19 13:28:09 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html


Note You need to log in before you can comment on or make changes to this bug.