Description of problem: mtr crashes with a segmentation fault on Fedora 19 if an IPv6 nameserver is specified in /etc/resolv.conf. A workaround is to call it with --no-dns, but this should rather be patched. A fix is available on https://github.com/mutantmonkey/mtr/commit/cece39e9fad8d53a1e41cae57348f5ab41ec3ba4 Version-Release number of selected component (if applicable): 0.84 is affected. It seems that there is no new upstream release with the fix yet. How reproducible: Add an IPv6 nameserver to resolv.conf (iff you have IPv6 connectivity) within the first three. E.g. 2001:4860:4860::8888. Start mtr to trace to any IP address. Observe a segmentation fault instead of a trace.
Let N be the number of configured IPv6 nameservers in /etc/resolv.conf. The bug occurs if and only if among the first N nameservers configured in /etc/resolv.conf there are IPv4 nameservers. For example, if you have one IPv6 nameserver and one IPv4 nameserver, the bug will occur if the IPv4 nameserver is listed first in /etc/resolv.conf, and it will not occur if the IPv6 nameserver is listed first. This is because the author of dns.c assumed that the first myres.nscount6 elements of the myres._u._ext.nsaddrs array are elements corresponding to the configured IPv6 nameservers. (myres._u._ext.nsaddrs is an array of pointers to struct sockaddr_in6.) However, the array also contains elements corresponding to IPv4 nameservers. These elements are 0. (I am not familiar with the glibc _res structure --which myres is aliased to--, so I don't know whether this is in fact a bug in glibc and not mtr.) The first myres.nscount6 elements of myres._u._ext.nsaddrs are dereferenced in ll. 940-941 of dns.c (line number from the source packaged for F19, it is ll. 937-938 in the pre-diff version of the patch linked above), hence the segmentation fault. While the proposed patch will fix the crash, it is incorrect insofar as with it, not all IPv6 nameservers may be considered for DNS lookup, i.e. when they are not listed as one of the first N nameservers in /etc/resolv.conf, even though it was clearly the intention of the original author of dns.c to query all configured nameservers.
Created attachment 779291 [details] Fix NSSOCKADDR6 null dereferences I have attached a patch which fixes the crash while preserving functionality. The patch works against the sources packaged for F19.
Hi Benedikt, thanks for the patch. What do you think if we keep this simple and use something like this ? Basically I am proposing iterating through all entries but picking only those we care about. for (i = 0; i < msres.nscount; ++i) { if (!ipv6) continue; // do stuff } Ordering in myres._u._ext.nsaddrs is not consistent with myres.ns_addrlist. Later doesn't depend on the order in /etc/resolv.conf. This might be bug in glibc. I have to check on that with glibc maintainers. Again thanks for the patch. Cheers, Michal
I opened pull request on github in order to get this fixed[1]. Upstream maintainer already merged the patch. [1] https://github.com/traviscross/mtr/pull/32
mtr-0.84-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mtr-0.84-3.fc19
mtr-0.85-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mtr-0.85-3.fc20
Package mtr-0.85-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mtr-0.85-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18584/mtr-0.85-3.fc20 then log in and leave karma (feedback).
mtr-0.85-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mtr-0.84-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.