When doing a reverse lookup on an argument that looks like an IPv6 address but contains too many octets, the process aborts with malloc(): memory corruption. The memory corruption occurs both with 1.6.12 on a stable system and 1.6.17 and on a ~amd64 system. i.e. `drill -x 2a01:0000:0000:0000:0000:0000:0000:0000:0000:0000:0000:0000:0000' causes: Output from above command attached Reporting here instead of upstream because the issue is not reproducible on FreeBSD (using the same version of drill) and the error seems to be in the libc
Created attachment 455756 [details] Output of failing drill -x
So this is more likely a bug in glibc, not?
(In reply to Marc Schiffbauer from comment #2) > So this is more likely a bug in glibc, not? After running the failing command under gdb (with debug information) I get the following call stack: #0 0x00007ffff73dc118 in raise () from /lib64/libc.so.6 #1 0x00007ffff73dd56a in abort () from /lib64/libc.so.6 #2 0x00007ffff7418b41 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff741e3d6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007ffff7420329 in _int_malloc () from /lib64/libc.so.6 #5 0x00007ffff7422174 in malloc () from /lib64/libc.so.6 #6 0x00007ffff7bb2a26 in ldns_rdf_new_frm_data () from /usr/lib64/libldns.so.1 #7 0x00007ffff7bbb779 in ldns_str2rdf_dname.part () from /usr/lib64/libldns.so.1 #8 0x00007ffff7bb2da8 in ldns_rdf_new_frm_str () from /usr/lib64/libldns.so.1 #9 0x000000000040540b in main () So the error is (probably) not actually in the libc, the longish call stack just confused me. Then again, since the issue doesn't occur on FreeBSD it might be in relation to the glibc malloc implementation. To be honest, I wasn't sure where to report this issue and it was definitely ldns related so I reported it here in the hope that someone with more knowledge could figure out which upstream to forward it to.
Ok, thank you. Would you mind to report it ldns upstream then? TIA
(In reply to Marc Schiffbauer from comment #4) > Ok, thank you. Would you mind to report it ldns upstream then? TIA Sure. Upstream Ticket here: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1192
The bug was fixed upstream and is in version 1.7.0 which was released yesterday. As soon as that release hits the tree this can be closed.
Fixed with following commit. commit cae976164ebd9191be909cf57f40992760f6a04a Author: Marc Schiffbauer <mschiff@gentoo.org> Date: Wed Dec 21 15:37:00 2016 +0100 net-dns/ldns-utils: bump version Package-Manager: Portage-2.3.3, Repoman-2.3.1
