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
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
