Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Michael Biebl]

Hi Rostislav!

Am 12.03.2016 um 01:08 schrieb Rostislav Pehlivanov:
> Actually, I'm still getting a crash.
> Managed to run systemd-resolved with gdb, here's the output
> 
> 
> sudo gdb --args /lib/systemd/systemd-resolved
>  [0]
...
> 
> Maybe it's an upstream bug?

I guess so. Would be great if you can file this issue upstream at
https://github.com/systemd/systemd/issues and attach the backtrace.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Rostislav Pehlivanov]

Actually, I'm still getting a crash.
Managed to run systemd-resolved with gdb, here's the output


sudo gdb --args /lib/systemd/systemd-resolved
 [0]
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /lib/systemd/systemd-resolved...Reading symbols from
/usr/lib/debug/.build-id/67/0bbd3d46aee6e92f76f271c40e238a1b48aed7.debug...done.
done.
(gdb) run
Starting program: /lib/systemd/systemd-resolved
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Positive Trust Anchors:
. IN DS19036 8 2
49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa
17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa
20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa
23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa
26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa
29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa
168.192.in-addr.arpa corp home internal intranet lan local private test
Using system hostname 'moonbase'.
Switching to system DNS server 84.200.69.80.
Switching to DNS server 192.168.1.1 for interface wlp2s0.
Using degraded feature set (UDP+EDNS0) for DNS server 192.168.1.1.
DNSSEC validation failed for question bg. IN SOA: failed-auxiliary
DNSSEC validation failed for question abv.bg. IN DS: failed-auxiliary
DNSSEC validation failed for question abv.bg. IN SOA: failed-auxiliary
DNSSEC validation failed for question abv.bg. IN A: failed-auxiliary

Program received signal SIGSEGV, Segmentation fault.
DNS_PACKET_SHALL_CACHE () at ../src/resolve/resolved-dns-packet.h:211
211 ../src/resolve/resolved-dns-packet.h: No such file or directory.
(gdb) br
Breakpoint 1 at 0x5557c147: file ../src/resolve/resolved-dns-packet.h,
line 211.
(gdb) bt
#0  DNS_PACKET_SHALL_CACHE () at ../src/resolve/resolved-dns-packet.h:211
#1  dns_transaction_cache_answer (t=0x5561ac00) at
../src/resolve/resolved-dns-transaction.c:584
#2  dns_transaction_process_dnssec.lto_priv.376 (t=t@entry=0x5561ac00)
at ../src/resolve/resolved-dns-transaction.c:719
#3  0x5557b9ad in dns_transaction_notify (source=0x5561d400,
t=0x5561ac00)
at ../src/resolve/resolved-dns-transaction.c:2076
#4  dns_transaction_complete (t=t@entry=0x5561d400, state=state@entry
=DNS_TRANSACTION_SUCCESS)
at ../src/resolve/resolved-dns-transaction.c:359
#5  0x5557bec5 in dns_transaction_process_dnssec.lto_priv.376
(t=)
at ../src/resolve/resolved-dns-transaction.c:722
#6  0x555a5968 in dns_transaction_process_reply
(t=t@entry=0x5561d400,
p=p@entry=0x5561e750)
at ../src/resolve/resolved-dns-transaction.c:1004
#7  0x555a694b in on_dns_packet (s=, fd=, revents=, userdata=0x5561d400)
at ../src/resolve/resolved-dns-transaction.c:1055
#8  0x5557ae03 in source_dispatch.lto_priv.472 (s=0x5561e550)
at ../src/libsystemd/sd-event/sd-event.c:2265
#9  0x555661dd in sd_event_dispatch (e=0x555fc860) at
../src/libsystemd/sd-event/sd-event.c:2625
#10 sd_event_run (timeout=18446744073709551615, e=0x555fc860) at
../src/libsystemd/sd-event/sd-event.c:2684
#11 sd_event_loop (e=0x555fc860) at
../src/libsystemd/sd-event/sd-event.c:2704
#12 main (argc=, argv=) at
../src/resolve/resolved.c:98
(gdb)


Maybe it's an upstream bug?

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Yuriy M. Kaminskiy]

On 03/09/16, Rostislav Pehlivanov wrote:
> Upgrading to the latest libnss3 (3.23) fixes the problem.

libnss3 is crypto library by mozilla, it is not related anyhow to name 
resolution and glibc nss subsystem, it is not used by systemd, and very 
unlikely to affect this bug anyhow. So, if this problem was fixed, it 
was something else.


P.S. if problem will reappear, to debug daemons that cannot be launched 
from gdb, you can either attach to them in gdb alive (gdb 
/path/to/daemon `pidof daemon`) or enable coredumps (take a look at 
systemd-coredump) and do post-mortem examination (gdb /path/to/daemon 
/path/to/core).

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Rostislav Pehlivanov]

Upgrading to the latest libnss3 (3.23) fixes the problem.
Since the bug has been fixed could the maintainers close it?

Thanks

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Rostislav Pehlivanov]

Package: libnss-resolve
Version: 229-2
Severity: important

Dear maintainer:

If systemd-resolve is used as the default system dns resolver
(by replacing "dns" inside /etc/nsswitch.conf with "resolve"),
the process handling the resolving "/lib/systemd/systemd-resolved"
started by the service systemd-resolved will segfault upon domain name
resolution (e.g. ping  will crash the process). The service
gets restarted immediately after it segfaults and is able to resolve the
first domain name (but with a short delay), so it's mostly transparent
to the end user. However the dmesg log quickly gets filled with entries like:

"[ 7620.719971] systemd-resolve[3655]: segfault at 5c ip 5625f5934147 sp 
7ffc5acd7380 error 4 in systemd-resolved[5625f590c000+9d000"

I believe it started after libc6 was updated in Debian unstable, though
I am not sure it was the cause.

I did try to run gdb to at least find out where it crashes, but the process
doesn't function as it should without it being started as a service.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-rc6-youmu (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnss-resolve depends on:
ii  libc62.22-1
ii  libselinux1  2.4-3+b1
ii  systemd  229-2

libnss-resolve recommends no packages.

libnss-resolve suggests no packages.

-- no debconf information