Bug 1393909

Created attachment 1219438 [details]
File: backtrace

Created attachment 1219439 [details]
File: cgroup

Created attachment 1219440 [details]
File: core_backtrace

Created attachment 1219441 [details]
File: dso_list

Created attachment 1219442 [details]
File: environ

Created attachment 1219443 [details]
File: exploitable

Created attachment 1219444 [details]
File: limits

Created attachment 1219445 [details]
File: maps

Created attachment 1219446 [details]
File: mountinfo

Created attachment 1219447 [details]
File: namespaces

Created attachment 1219448 [details]
File: open_fds

Created attachment 1219449 [details]
File: proc_pid_status

Created attachment 1219450 [details]
File: var_log_messages

Additional information:  I'm on a VPN (PPTP).

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 enp0s8
10.0.0.0        0.0.0.0         255.255.255.0   U     50     0        0 ppp0
10.0.0.42       0.0.0.0         255.255.255.255 UH    50     0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s8
213.218.195.63  192.168.1.1     255.255.255.255 UGH   0      0        0 enp0s8

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
Segmentation fault (core dumped)

Very similar problem, according to GDB:

#0  0x00007ffff01fecfe in __pthread_initialize_minimal_internal () from /lib64/libpthread.so.0
#1  0x00007ffff01fe549 in _init () from /lib64/libpthread.so.0
#2  0x00007ffff04157b0 in ?? () from /lib64/libnss_mdns4_minimal.so.2
...
#13 0x00007ffff782373a in gethostbyaddr_r@@GLIBC_2.2.5 () from /lib64/libc.so.6
#14 0x00007ffff782b978 in gni_host_inet_name.isra () from /lib64/libc.so.6

"route -n" vs. "route" -- looks like something wrong in DNS resolving code.
Reassign to glibc.

Would you please try to reproduce this with glibc-debuginfo and nss-mdns-debuginfo install, and post “bt full” output?  Thanks.

Created attachment 1219465 [details]
Backtrace from route

Attached backtrace after running route.

Created attachment 1219466 [details]
Backtrace from traceroute

Attached backtrace from running traceroute.

Could you run “rpm -V glibc nss-mdns” and paste the output, please?

I can't explain the backtraces you get based on the file contents of /lib64/libnss_mdns4_minimal.so.2, so maybe the file is corrupted.

# rpm -V glibc nss-mdns
[no output]

# rpm -V glibc-debuginfo nss-mdns-debuginfo
[no output]

(Needed to be root to read two files for glibc in /usr/sbin)

I can reproduce the issue if I add any non-local network destination in my routing tables, e.g.

# route add www.google.co.uk gw 192.168.1.99

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         BrightBox.ee    0.0.0.0         UG    100    0        0 enp0s8
Segmentation fault (core dumped)

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 enp0s8
172.217.23.3    192.168.1.99    255.255.255.255 UGH   0      0        0 enp0s8
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s8

Hmm, can you run route under valgrind, using “valgrind route”?  Maybe this is plain old memory corruption.

I will try to replicate this, but the issue may depend on your local network and its mDNS responders.

Created attachment 1219510 [details]
Output of valgrind

Attached output of valgrind (success + failure cases).

Still no idea.  Does this crash as well:

python -c 'import socket; print socket.getnameinfo(("172.217.23.3", 80), 0)'

Or this?

python -c 'import socket; print socket.getnameinfo(("192.168.1.99", 80), 0)'

$ python -c 'import socket; print socket.getnameinfo(("172.217.23.3", 80), 0)'
('lhr35s01-in-f3.1e100.net', 'http')

$ python -c 'import socket; print socket.getnameinfo(("192.168.1.99", 80), 0)'
('192.168.1.99', 'http')

From a quick glance at the source along with gdb, it's getting stuck on:

  THREAD_SETMEM (pd, cpuclock_offset, GL(dl_cpuclock_offset));

If setting that field fails, why do the previous ones (lines 317+318) succeed?

(In reply to mj.wilson.uk from comment #24)
> $ python -c 'import socket; print socket.getnameinfo(("172.217.23.3", 80),
> 0)'
> ('lhr35s01-in-f3.1e100.net', 'http')
> 
> $ python -c 'import socket; print socket.getnameinfo(("192.168.1.99", 80),
> 0)'
> ('192.168.1.99', 'http')

Next candidate:

python -c 'import socket; print socket.getnameinfo(("255.255.255.255", 80), 0)'

> From a quick glance at the source along with gdb, it's getting stuck on:
> 
>   THREAD_SETMEM (pd, cpuclock_offset, GL(dl_cpuclock_offset));
> 
> If setting that field fails, why do the previous ones (lines 317+318)
> succeed?

This code should not run *at all*.  It is for libpthread initialization, but libnss_mdns4_minimal.so.2 isn't linked against libpthread.  Maybe the code is in fact loading *another* NSS module after libnss_mdns4_minimal.so.2, and the backtrace is misleading because the stack has been corrupted.

What's the contents of the “hosts” line in /etc/nsswitch.conf?

What happens if you run “LD_DEBUG=files /sbin/route” in the crashing case?

Created attachment 1219526 [details]
LD_DEBUG=files route

/etc/nsswitch.conf:

hosts:      files dns wins mdns4_minimal myhostname mymachines

Seems to be unaltered from the rpm (AFAICT).

Attached the output with LD_DEBUG=files.

Okay, I can reproduce it after adding “wins“ to the “hosts” line.  Now we are getting somewhere!

Reduced test case:

#include <dlfcn.h>
#include <err.h>
#include <stdio.h>

int
main (void)
{
  void *handle = dlopen ("libnss_wins.so.2", RTLD_LAZY);
  printf ("handle: %p\n", handle);
  printf ("error: %s\n", dlerror ());
  handle = dlopen ("libnss_mdns4_minimal.so.2", RTLD_LAZY);
  printf ("handle: %p\n", handle);
  printf ("error: %s\n", dlerror ());
}

This is triggered because loading libnss_wins.so.2 fails due to a missing library (libreplace-samba4.so), for which libnss_wins.so.2 as a DT_NEEDED entry.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fixed in glibc 2.25.