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.
Looks like this issue
https:/
Quoting:
The announcement of CVE-2015-7547 said:
“
- Always malloc the second response buffer if needed.
- Requires fix for sourceware bug 16574 to avoid memory leak.
commit d668061994a7486
commit ab09bf616ad527b
”
<https:/
Coincidentally, this regression originally delayed the disclosure of CVE-2015-7547. The upstream glibc 2.19 branch already had the fix for bug 16574 when CVE-2015-7547 was fixed, but our downstream 2.12 and 2.17 branches still needed it.
If you have you own resolv backports, you should really try to get a valgrind-clean pass with the external resolv test suite:
<https:/