Your message dated Sat, 1 Dec 2018 11:44:40 +0100
with message-id <[email protected]>
and subject line Re: Bug#914124: Another backtrace
has caused the Debian Bug report #914124,
regarding bind9: crash on assertion dns_rdata_compare (DNSSEC validation)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
914124: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914124
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bind9
Version: 1:9.10.3.dfsg.P4-12.3+deb9u4
Severity: normal
Tags: security
-- System Information:
Debian Release: 9.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 4.18.12-00102-g0c3a1e31342c (SMP w/4 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8),
LANGUAGE=uk_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bind9 depends on:
ii adduser 3.115
ii bind9utils 1:9.10.3.dfsg.P4-12.3+deb9u4
ii debconf [debconf-2.0] 1.5.61
ii init-system-helpers 1.48
ii libbind9-140 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libc6 2.24-11+deb9u3
ii libcap2 1:2.25-1
ii libcomerr2 1.43.4-2
ii libdns162 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libgeoip1 1.6.9-4
ii libgssapi-krb5-2 1.15-1+deb9u1
ii libirs141 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libisc160 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libisccc140 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libisccfg140 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libk5crypto3 1.15-1+deb9u1
ii libkrb5-3 1.15-1+deb9u1
ii liblwres141 1:9.10.3.dfsg.P4-12.3+deb9u4
ii libssl1.0.2 1.0.2l-2+deb9u3
ii libxml2 2.9.4+dfsg1-2.2+deb9u2
ii lsb-base 9.20161125
ii net-tools 1.60+git20161116.90da8a0-1
ii netbase 5.4
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind9-doc <none>
ii dnsutils 1:9.10.3.dfsg.P4-12.3+deb9u4
pn resolvconf <none>
pn ufw <none>
-- debconf information:
bind9/run-resolvconf: false
bind9/start-as-user: bind
bind9/different-configuration-file:
journald log:
лис 18 19:32:36 ns2 named[3755]: validating
7motvktev4n1ka4dgv1cs2glvdo21jt8.info/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating
CK0POJMG874LJREF7EFN8430QVIT8BSM.com/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating
0FJ2QRUKV8KMK7RR9HII364N389JQPHG.com/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating
3RL2Q58205687C8I9KC9MV46DGHCNS45.com/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating org/SOA: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating
u9f4lg857iv7inmut8bqmcjqm96le7t9.org/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating
vait3kqm4ddfgbgsl5ch2adeqcdaekt4.org/NSEC3: no valid signature found
лис 18 19:32:36 ns2 named[3755]: validating org/SOA: no valid signature found
лис 18 19:32:36 ns2 named[3755]: ../../../lib/dns/rdata.c:420:
REQUIRE((((rdata1)->flags & ~(0x0001|0x0002)) == 0)) failed.
лис 18 19:32:36 ns2 systemd[1]: bind9.service: Main process exited,
code=killed, status=6/ABRT
лис 18 19:32:55 ns2 rndc[29660]: rndc: connect failed: 127.0.0.1#953:
connection refused
лис 18 19:32:55 ns2 systemd[1]: bind9.service: Control process exited,
code=exited status=1
лис 18 19:32:55 ns2 systemd[1]: bind9.service: Unit entered failed state.
лис 18 19:32:55 ns2 systemd[1]: bind9.service: Failed with result 'signal'.
Server configured as recursive resolver for the local network.
Trying to find out codepath lead to the crash.
--- End Message ---
--- Begin Message ---
--
Ondřej Surý <[email protected]>
> On 1 Dec 2018, at 11:17, Philippe Duke <[email protected]> wrote:
>
> Hello, Ondřej
>
> It is clear - hardware bug for now. Board died soon after very weird
> sequence of errors.
>
> Seems like on-board DDR memory corruption. For now on, it is nothing to
> worry about, at least for now.
>
>
> Apologize for the inconvenience, my fault - to forget double-check it.
>
> Close the bug ticket please.
>
>
> 01.12.18 11:22, Ondřej Surý пише:
>> Hi Philippe,
>>
>> do you have any other conclusion from your investigation?
>>
>> Ondrej
>> --
>> Ondřej Surý
>> [email protected]
>>
>>
>>
>>> On 21 Nov 2018, at 23:47, Philippe Duke <[email protected]> wrote:
>>>
>>> (gdb)
>>> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>>> set = {__val = {16387, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>>> 281473428432960, 281473462095732, 281473463222272, 281473428443584,
>>> 281473428432960,
>>> 281473462095632}}
>>> pid = <optimized out>
>>> tid = <optimized out>
>>> #1 0x0000ffffa5b8cdf4 in __GI_abort () at abort.c:89
>>> save_stage = 2
>>> act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction =
>>> 0x0}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0,
>>> sa_restorer = 0x0}
>>> sigs = {__val = {32, 0 <repeats 15 times>}}
>>> #2 0x0000ffffa5bc4628 in __libc_message (do_abort=do_abort@entry=2,
>>> fmt=fmt@entry=0xffffa5c79f20 "*** %s ***: %s terminated\n")
>>> at ../sysdeps/posix/libc_fatal.c:175
>>> ap = {__stack = 0xffffa3b72c10, __gr_top = 0xffffa3b72c10,
>>> __vr_top = 0xffffa3b72be0, __gr_offs = -32, __vr_offs = -128}
>>> fd = 2
>>> on_2 = <optimized out>
>>> list = <optimized out>
>>> nlist = <optimized out>
>>> cp = <optimized out>
>>> written = <optimized out>
>>> #3 0x0000ffffa5c33398 in __GI___fortify_fail
>>> (msg=msg@entry=0xffffa5c79f08 "stack smashing detected") at
>>> fortify_fail.c:30
>>> No locals.
>>> #4 0x0000ffffa5c3334c in __stack_chk_fail () at stack_chk_fail.c:28
>>> No locals.
>>> #5 0x0000ffffa6481c48 in dns_rdataset_additionaldata
>>> (rdataset=0xffff9bbb8b70, add=0xaaaabd7ff648 <query_addadditional2>,
>>> arg=0xffffa3b72d38)
>>> at ../../../lib/dns/rdataset.c:642
>>> rdata = {data = 0xffffa3b72ec0 "", length = 0, rdclass = 0, type
>>> = 0, flags = 0, link = {prev = 0x0, next = 0x0}}
>>> result = <optimized out>
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>>
>>>
>>> Another one. Looking up for hardware issue. Recompling with ARM errata
>>> mitigations. But this is really weird anyway.
>>>
>>> --
>>> Philippe Duke
>>> Network software engineer
>>> System-level developer
>>>
>>> NetAssist LLC
>>> Ukraine
>>> Khreshchatyk Street, 10B, office 8
>>> AS29632
>>>
>>> http://netassist.ua
>>> Our GitHub Repository:
>>> https://github.com/netassist-ua
>>>
> --
> Philippe Duke
> Network software engineer
> System-level developer
>
> NetAssist LLC
> Ukraine
> Khreshchatyk Street, 10B, office 8
> AS29632
>
> http://netassist.ua
> Our GitHub Repository:
> https://github.com/netassist-ua
>
>
--- End Message ---
