eglibc 2.19 leaks memory on getaddrinfo

Bug #1719959 reported by Max Dymond on 2017-09-27
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)
Undecided
Unassigned

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.

CVE References

Florian Weimer (fweimer) wrote :

Looks like this issue

  https://sourceware.org/bugzilla/show_bug.cgi?id=21336#c16

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 d668061994a7486a3ba9c7d5e7882d85a2883707
    commit ab09bf616ad527b249aca5f2a4956fd526f0712f

<https://www.sourceware.org/ml/libc-alpha/2016-02/msg00416.html>

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://pagure.io/glibc-resolv-tests>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.