Public bug reported: eglibc 2.19-0ubuntu6.13 is leaking memory when getaddrinfo is called with a bad address.
Ubuntu version: 14.04.5 LTS We're using Travis CI to do our CI. https://travis-ci.org/curl/curl- fuzzer/builds/279417251 exhibits a memory leak when attempting to do a lookup on the fqdn "t.." I've done a bit of investigation - the memory is allocated here: Direct leak of 65536 byte(s) in 1 object(s) allocated from: #0 0x4be69c in __interceptor_malloc /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3 #1 0x7ffff513bd05 in send_dg /build/eglibc-SvCtMH/eglibc-2.19/resolv/res_send.c:1369 #2 0x7ffff513bd05 in __libc_res_nsend /build/eglibc-SvCtMH/eglibc-2.19/resolv/res_send.c:576 Backtrace at point of allocation is: (gdb) bt #0 __libc_res_nsend (statp=statp@entry=0x7ffff02ffdb8, buf=buf@entry=0x7ffff02fc360 "\t:\001", buflen=19, buf2=buf2@entry=0x7ffff02fc374 "\371%\001", buflen2=buflen2@entry=19, ans=ans@entry=0x7ffff02fcf70 "\t:\201\203", anssiz=anssiz@entry=2048, ansp=ansp@entry=0x7ffff02fd7e0, ansp2=ansp2@entry=0x7ffff02fd7f0, nansp2=nansp2@entry=0x7ffff02fd7a0, resplen2=resplen2@entry=0x7ffff02fd7b0, ansp2_malloced=ansp2_malloced@entry=0x7ffff02fd7c0) at res_send.c:580 #1 0x00007ffff5138e2c in __GI___libc_res_nquery (statp=statp@entry=0x7ffff02ffdb8, name=0x7ffff02fcaf0 "t.", class=class@entry=1, type=type@entry=62321, answer=answer@entry=0x7ffff02fcf70 "\t:\201\203", anslen=anslen@entry=2048, answerp=answerp@entry=0x7ffff02fd7e0, answerp2=answerp2@entry=0x7ffff02fd7f0, nanswerp2=nanswerp2@entry=0x7ffff02fd7a0, resplen2=resplen2@entry=0x7ffff02fd7b0, answerp2_malloced=answerp2_malloced@entry=0x7ffff02fd7c0) at res_query.c:227 #2 0x00007ffff5139863 in __libc_res_nquerydomain (domain=0x0, answerp2_malloced=0x7ffff02fd7c0, resplen2=0x7ffff02fd7b0, nanswerp2=0x7ffff02fd7a0, answerp2=0x7ffff02fd7f0, answerp=0x7ffff02fd7e0, anslen=2048, answer=0x7ffff02fcf70 "\t:\201\203", type=62321, class=1, name=0x603000023f28 "t..", statp=0x7ffff02ffdb8) at res_query.c:591 #3 __GI___libc_res_nsearch (statp=0x7ffff02ffdb8, name=name@entry=0x603000023f28 "t..", class=class@entry=1, type=type@entry=62321, answer=answer@entry=0x7ffff02fcf70 "\t:\201\203", anslen=anslen@entry=2048, answerp=answerp@entry=0x7ffff02fd7e0, answerp2=answerp2@entry=0x7ffff02fd7f0, nanswerp2=nanswerp2@entry=0x7ffff02fd7a0, resplen2=resplen2@entry=0x7ffff02fd7b0, answerp2_malloced=answerp2_malloced@entry=0x7ffff02fd7c0) at res_query.c:381 #4 0x00007fffef6f0c73 in _nss_dns_gethostbyname4_r (name=name@entry=0x603000023f28 "t..", pat=pat@entry=0x7ffff02fde00, buffer=buffer@entry=0x7ffff02fd890 "\177", buflen=buflen@entry=1064, errnop=errnop@entry=0x7ffff02fddd0, herrnop=herrnop@entry=0x7ffff02fde30, ttlp=ttlp@entry=0x0) at nss_dns/dns-host.c:315 #5 0x00007ffff595a636 in gaih_inet (name=<optimized out>, name@entry=0x603000023f28 "t..", service=<optimized out>, req=req@entry=0x60d00000cfb8, pai=pai@entry=0x7ffff02fdf40, naddrs=naddrs@entry=0x7ffff02fdf30) at ../sysdeps/posix/getaddrinfo.c:858 #6 0x00007ffff595d93d in __GI_getaddrinfo (name=0x603000023f28 "t..", service=0x7ffff02fec60 "80", hints=0x60d00000cfb8, pai=0x7ffff02fe9a0) at ../sysdeps/posix/getaddrinfo.c:2414 #7 0x0000000000449825 in __interceptor_getaddrinfo () at /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2169 #8 0x000000000051dbe5 in curl_dogetaddrinfo (hostname=0x603000023f28 "t..", service=0x7ffff02fec60 "80", hints=0x60d00000cfb8, result=0x7ffff02fe9a0, line=124, source=0x6c3f60 <.str> "curl_addrinfo.c") at curl_addrinfo.c:575 #9 0x000000000051cf81 in Curl_getaddrinfo_ex (nodename=0x603000023f28 "t..", servname=0x7ffff02fec60 "80", hints=0x60d00000cfb8, result=0x60d00000cfb0) at curl_addrinfo.c:124 #10 0x00000000005275f7 in getaddrinfo_thread (arg=0x60d00000cf90) at asyn-thread.c:279 #11 0x000000000062e71a in curl_thread_create_thunk (arg=0x603000023e98) at curl_threads.c:57 #12 0x00007ffff6897184 in start_thread (arg=0x7ffff02ff700) at pthread_create.c:312 #13 0x00007ffff5987ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Let me know if any further diagnostics would be helpful. It's 100% reproducible on Travis. ** Affects: eglibc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to eglibc in Ubuntu. https://bugs.launchpad.net/bugs/1719959 Title: eglibc 2.19 leaks memory on getaddrinfo Status in eglibc package in Ubuntu: New Bug description: eglibc 2.19-0ubuntu6.13 is leaking memory when getaddrinfo is called with a bad address. Ubuntu version: 14.04.5 LTS We're using Travis CI to do our CI. https://travis-ci.org/curl/curl- fuzzer/builds/279417251 exhibits a memory leak when attempting to do a lookup on the fqdn "t.." I've done a bit of investigation - the memory is allocated here: Direct leak of 65536 byte(s) in 1 object(s) allocated from: #0 0x4be69c in __interceptor_malloc /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3 #1 0x7ffff513bd05 in send_dg /build/eglibc-SvCtMH/eglibc-2.19/resolv/res_send.c:1369 #2 0x7ffff513bd05 in __libc_res_nsend /build/eglibc-SvCtMH/eglibc-2.19/resolv/res_send.c:576 Backtrace at point of allocation is: (gdb) bt #0 __libc_res_nsend (statp=statp@entry=0x7ffff02ffdb8, buf=buf@entry=0x7ffff02fc360 "\t:\001", buflen=19, buf2=buf2@entry=0x7ffff02fc374 "\371%\001", buflen2=buflen2@entry=19, ans=ans@entry=0x7ffff02fcf70 "\t:\201\203", anssiz=anssiz@entry=2048, ansp=ansp@entry=0x7ffff02fd7e0, ansp2=ansp2@entry=0x7ffff02fd7f0, nansp2=nansp2@entry=0x7ffff02fd7a0, resplen2=resplen2@entry=0x7ffff02fd7b0, ansp2_malloced=ansp2_malloced@entry=0x7ffff02fd7c0) at res_send.c:580 #1 0x00007ffff5138e2c in __GI___libc_res_nquery (statp=statp@entry=0x7ffff02ffdb8, name=0x7ffff02fcaf0 "t.", class=class@entry=1, type=type@entry=62321, answer=answer@entry=0x7ffff02fcf70 "\t:\201\203", anslen=anslen@entry=2048, answerp=answerp@entry=0x7ffff02fd7e0, answerp2=answerp2@entry=0x7ffff02fd7f0, nanswerp2=nanswerp2@entry=0x7ffff02fd7a0, resplen2=resplen2@entry=0x7ffff02fd7b0, answerp2_malloced=answerp2_malloced@entry=0x7ffff02fd7c0) at res_query.c:227 #2 0x00007ffff5139863 in __libc_res_nquerydomain (domain=0x0, answerp2_malloced=0x7ffff02fd7c0, resplen2=0x7ffff02fd7b0, nanswerp2=0x7ffff02fd7a0, answerp2=0x7ffff02fd7f0, answerp=0x7ffff02fd7e0, anslen=2048, answer=0x7ffff02fcf70 "\t:\201\203", type=62321, class=1, name=0x603000023f28 "t..", statp=0x7ffff02ffdb8) at res_query.c:591 #3 __GI___libc_res_nsearch (statp=0x7ffff02ffdb8, name=name@entry=0x603000023f28 "t..", class=class@entry=1, type=type@entry=62321, answer=answer@entry=0x7ffff02fcf70 "\t:\201\203", anslen=anslen@entry=2048, answerp=answerp@entry=0x7ffff02fd7e0, answerp2=answerp2@entry=0x7ffff02fd7f0, nanswerp2=nanswerp2@entry=0x7ffff02fd7a0, resplen2=resplen2@entry=0x7ffff02fd7b0, answerp2_malloced=answerp2_malloced@entry=0x7ffff02fd7c0) at res_query.c:381 #4 0x00007fffef6f0c73 in _nss_dns_gethostbyname4_r (name=name@entry=0x603000023f28 "t..", pat=pat@entry=0x7ffff02fde00, buffer=buffer@entry=0x7ffff02fd890 "\177", buflen=buflen@entry=1064, errnop=errnop@entry=0x7ffff02fddd0, herrnop=herrnop@entry=0x7ffff02fde30, ttlp=ttlp@entry=0x0) at nss_dns/dns-host.c:315 #5 0x00007ffff595a636 in gaih_inet (name=<optimized out>, name@entry=0x603000023f28 "t..", service=<optimized out>, req=req@entry=0x60d00000cfb8, pai=pai@entry=0x7ffff02fdf40, naddrs=naddrs@entry=0x7ffff02fdf30) at ../sysdeps/posix/getaddrinfo.c:858 #6 0x00007ffff595d93d in __GI_getaddrinfo (name=0x603000023f28 "t..", service=0x7ffff02fec60 "80", hints=0x60d00000cfb8, pai=0x7ffff02fe9a0) at ../sysdeps/posix/getaddrinfo.c:2414 #7 0x0000000000449825 in __interceptor_getaddrinfo () at /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2169 #8 0x000000000051dbe5 in curl_dogetaddrinfo (hostname=0x603000023f28 "t..", service=0x7ffff02fec60 "80", hints=0x60d00000cfb8, result=0x7ffff02fe9a0, line=124, source=0x6c3f60 <.str> "curl_addrinfo.c") at curl_addrinfo.c:575 #9 0x000000000051cf81 in Curl_getaddrinfo_ex (nodename=0x603000023f28 "t..", servname=0x7ffff02fec60 "80", hints=0x60d00000cfb8, result=0x60d00000cfb0) at curl_addrinfo.c:124 #10 0x00000000005275f7 in getaddrinfo_thread (arg=0x60d00000cf90) at asyn-thread.c:279 #11 0x000000000062e71a in curl_thread_create_thunk (arg=0x603000023e98) at curl_threads.c:57 #12 0x00007ffff6897184 in start_thread (arg=0x7ffff02ff700) at pthread_create.c:312 #13 0x00007ffff5987ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Let me know if any further diagnostics would be helpful. It's 100% reproducible on Travis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1719959/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
