[Bug 1719959] Re: eglibc 2.19 leaks memory on getaddrinfo

Wed Sep 27 18:02:37 UTC 2017

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>

** Bug watch added: Sourceware.org Bugzilla #21336
   https://sourceware.org/bugzilla/show_bug.cgi?id=21336

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2015-7547

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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 at entry=0x7ffff02ffdb8, buf=buf at entry=0x7ffff02fc360 "\t:\001", buflen=19, buf2=buf2 at entry=0x7ffff02fc374 "\371%\001", buflen2=buflen2 at entry=19,
      ans=ans at entry=0x7ffff02fcf70 "\t:\201\203", anssiz=anssiz at entry=2048, ansp=ansp at entry=0x7ffff02fd7e0, ansp2=ansp2 at entry=0x7ffff02fd7f0, nansp2=nansp2 at entry=0x7ffff02fd7a0,
      resplen2=resplen2 at entry=0x7ffff02fd7b0, ansp2_malloced=ansp2_malloced at entry=0x7ffff02fd7c0) at res_send.c:580
  #1  0x00007ffff5138e2c in __GI___libc_res_nquery (statp=statp at entry=0x7ffff02ffdb8, name=0x7ffff02fcaf0 "t.", class=class at entry=1, type=type at entry=62321, answer=answer at entry=0x7ffff02fcf70 "\t:\201\203",
      anslen=anslen at entry=2048, answerp=answerp at entry=0x7ffff02fd7e0, answerp2=answerp2 at entry=0x7ffff02fd7f0, nanswerp2=nanswerp2 at entry=0x7ffff02fd7a0, resplen2=resplen2 at entry=0x7ffff02fd7b0,
      answerp2_malloced=answerp2_malloced at 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 at entry=0x603000023f28 "t..", class=class at entry=1, type=type at entry=62321, answer=answer at entry=0x7ffff02fcf70 "\t:\201\203", anslen=anslen at entry=2048,
      answerp=answerp at entry=0x7ffff02fd7e0, answerp2=answerp2 at entry=0x7ffff02fd7f0, nanswerp2=nanswerp2 at entry=0x7ffff02fd7a0, resplen2=resplen2 at entry=0x7ffff02fd7b0,
      answerp2_malloced=answerp2_malloced at entry=0x7ffff02fd7c0) at res_query.c:381
  #4  0x00007fffef6f0c73 in _nss_dns_gethostbyname4_r (name=name at entry=0x603000023f28 "t..", pat=pat at entry=0x7ffff02fde00, buffer=buffer at entry=0x7ffff02fd890 "\177", buflen=buflen at entry=1064,
      errnop=errnop at entry=0x7ffff02fddd0, herrnop=herrnop at entry=0x7ffff02fde30, ttlp=ttlp at entry=0x0) at nss_dns/dns-host.c:315
  #5  0x00007ffff595a636 in gaih_inet (name=<optimized out>, name at entry=0x603000023f28 "t..", service=<optimized out>, req=req at entry=0x60d00000cfb8, pai=pai at entry=0x7ffff02fdf40, naddrs=naddrs at 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