| 2020-09-23 10:19:49 |
Marian Rainer-Harbach |
bug |
|
|
added bug |
| 2020-09-23 10:28:57 |
Marian Rainer-Harbach |
bug watch added |
|
https://gitlab.isc.org/isc-projects/bind9/-/issues/1997 |
|
| 2020-09-23 10:28:57 |
Marian Rainer-Harbach |
cve linked |
|
2020-8621 |
|
| 2020-09-23 10:29:26 |
Marian Rainer-Harbach |
information type |
Public |
Public Security |
|
| 2020-09-23 12:31:21 |
Andreas Hasenack |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969448 |
|
| 2020-09-23 12:31:21 |
Andreas Hasenack |
bug task added |
|
bind9 (Debian) |
|
| 2020-09-23 12:33:31 |
Andreas Hasenack |
bug task deleted |
bind9 (Debian) |
|
|
| 2020-09-23 12:34:58 |
Andreas Hasenack |
cve linked |
|
2020-8620 |
|
| 2020-09-25 06:38:23 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2020-09-25 06:38:29 |
Christian Ehrhardt |
tags |
focal |
focal server-next |
|
| 2020-09-28 09:48:51 |
Lars Stokholm |
bug |
|
|
added subscriber Lars Stokholm |
| 2020-09-28 15:02:45 |
Christian Ehrhardt |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2020-09-28 15:58:25 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2020-09-28 15:58:25 |
Christian Ehrhardt |
bug task added |
|
bind9 (Ubuntu Focal) |
|
| 2020-09-28 15:58:32 |
Christian Ehrhardt |
bind9 (Ubuntu): status |
New |
Fix Released |
|
| 2020-09-28 15:58:34 |
Christian Ehrhardt |
bind9 (Ubuntu Focal): status |
New |
Triaged |
|
| 2020-10-05 08:56:31 |
Erik Lüken |
bug |
|
|
added subscriber Erik Lüken |
| 2020-10-12 14:32:37 |
Christian Ehrhardt |
bind9 (Ubuntu Focal): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2020-10-12 15:32:17 |
Simon Déziel |
bug |
|
|
added subscriber Simon Déziel |
| 2020-10-12 17:28:44 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/bind9/+git/bind9/+merge/392144 |
|
| 2020-10-13 05:18:00 |
Christian Ehrhardt |
description |
I'm running Ubuntu 20.04 and bind9 1:9.16.1-0ubuntu2.3.
BIND sometimes crashes with:
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:15 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: resolver.c:5105: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
Sep 23 10:10:16 <hostname> named[1146]: #0 0x558b762dce43 in ??
Sep 23 10:10:16 <hostname> named[1146]: #1 0x7f390cf32ac0 in ??
Sep 23 10:10:16 <hostname> named[1146]: #2 0x7f390d0fb12d in ??
Sep 23 10:10:16 <hostname> named[1146]: #3 0x7f390d0fe940 in ??
Sep 23 10:10:16 <hostname> named[1146]: #4 0x7f390d104888 in ??
Sep 23 10:10:16 <hostname> named[1146]: #5 0x7f390d108f21 in ??
Sep 23 10:10:16 <hostname> named[1146]: #6 0x7f390d109a66 in ??
Sep 23 10:10:16 <hostname> named[1146]: #7 0x7f390d109ec6 in ??
Sep 23 10:10:16 <hostname> named[1146]: #8 0x7f390cf59fe1 in ??
Sep 23 10:10:16 <hostname> named[1146]: #9 0x7f390ca22609 in ??
Sep 23 10:10:16 <hostname> named[1146]: #10 0x7f390c943103 in ??
Sep 23 10:10:16 <hostname> named[1146]: exiting (due to assertion failure)
The crash has ocurred repeatedly on multiple hosts.
In all cases I observed BIND has logged timeouts immediately before each crash. |
[Impact]
* There are rare configurations and situations that lead to bind9
code that works like an assert aborting the daemon.
It was found that these rare conditions can happen in some setups
and that a log-error would be better than an abort.
* Backport the upstream change to help the users affected by this issue.
[Test Case]
* Sadly we have no well isolated testcase yet, but an awesome and
responsive bug reporter who has a setup that usually triggered it a few
times over 1-2 weeks. Gladly the fix converts a former assert-abort
into a log warning. Therefore once we can check these logs and once the
messages appear know that the bug "would have happened but got fixed.
[Regression Potential]
* The change only is on a path that formerly was causing an abort of the
daemon. There a conversion of this assert to a log-warning should only
affect people that formerly had it crashing - and for them it is a fix.
Other use-cases should be unaffected.
Trying to think of regressions I can only come to e.g. CI-testcases
which expect fails on this case but now would work. Yet it would do so
as well with newer versions of bind as this is no Ubuntu Delta but a
backport.
[Other Info]
* n/a
---
I'm running Ubuntu 20.04 and bind9 1:9.16.1-0ubuntu2.3.
BIND sometimes crashes with:
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:15 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: resolver.c:5105: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
Sep 23 10:10:16 <hostname> named[1146]: #0 0x558b762dce43 in ??
Sep 23 10:10:16 <hostname> named[1146]: #1 0x7f390cf32ac0 in ??
Sep 23 10:10:16 <hostname> named[1146]: #2 0x7f390d0fb12d in ??
Sep 23 10:10:16 <hostname> named[1146]: #3 0x7f390d0fe940 in ??
Sep 23 10:10:16 <hostname> named[1146]: #4 0x7f390d104888 in ??
Sep 23 10:10:16 <hostname> named[1146]: #5 0x7f390d108f21 in ??
Sep 23 10:10:16 <hostname> named[1146]: #6 0x7f390d109a66 in ??
Sep 23 10:10:16 <hostname> named[1146]: #7 0x7f390d109ec6 in ??
Sep 23 10:10:16 <hostname> named[1146]: #8 0x7f390cf59fe1 in ??
Sep 23 10:10:16 <hostname> named[1146]: #9 0x7f390ca22609 in ??
Sep 23 10:10:16 <hostname> named[1146]: #10 0x7f390c943103 in ??
Sep 23 10:10:16 <hostname> named[1146]: exiting (due to assertion failure)
The crash has ocurred repeatedly on multiple hosts.
In all cases I observed BIND has logged timeouts immediately before each crash. |
|
| 2020-10-14 14:10:35 |
Robie Basak |
description |
[Impact]
* There are rare configurations and situations that lead to bind9
code that works like an assert aborting the daemon.
It was found that these rare conditions can happen in some setups
and that a log-error would be better than an abort.
* Backport the upstream change to help the users affected by this issue.
[Test Case]
* Sadly we have no well isolated testcase yet, but an awesome and
responsive bug reporter who has a setup that usually triggered it a few
times over 1-2 weeks. Gladly the fix converts a former assert-abort
into a log warning. Therefore once we can check these logs and once the
messages appear know that the bug "would have happened but got fixed.
[Regression Potential]
* The change only is on a path that formerly was causing an abort of the
daemon. There a conversion of this assert to a log-warning should only
affect people that formerly had it crashing - and for them it is a fix.
Other use-cases should be unaffected.
Trying to think of regressions I can only come to e.g. CI-testcases
which expect fails on this case but now would work. Yet it would do so
as well with newer versions of bind as this is no Ubuntu Delta but a
backport.
[Other Info]
* n/a
---
I'm running Ubuntu 20.04 and bind9 1:9.16.1-0ubuntu2.3.
BIND sometimes crashes with:
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:15 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: resolver.c:5105: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
Sep 23 10:10:16 <hostname> named[1146]: #0 0x558b762dce43 in ??
Sep 23 10:10:16 <hostname> named[1146]: #1 0x7f390cf32ac0 in ??
Sep 23 10:10:16 <hostname> named[1146]: #2 0x7f390d0fb12d in ??
Sep 23 10:10:16 <hostname> named[1146]: #3 0x7f390d0fe940 in ??
Sep 23 10:10:16 <hostname> named[1146]: #4 0x7f390d104888 in ??
Sep 23 10:10:16 <hostname> named[1146]: #5 0x7f390d108f21 in ??
Sep 23 10:10:16 <hostname> named[1146]: #6 0x7f390d109a66 in ??
Sep 23 10:10:16 <hostname> named[1146]: #7 0x7f390d109ec6 in ??
Sep 23 10:10:16 <hostname> named[1146]: #8 0x7f390cf59fe1 in ??
Sep 23 10:10:16 <hostname> named[1146]: #9 0x7f390ca22609 in ??
Sep 23 10:10:16 <hostname> named[1146]: #10 0x7f390c943103 in ??
Sep 23 10:10:16 <hostname> named[1146]: exiting (due to assertion failure)
The crash has ocurred repeatedly on multiple hosts.
In all cases I observed BIND has logged timeouts immediately before each crash. |
[Impact]
* There are rare configurations and situations that lead to bind9
code that works like an assert aborting the daemon.
It was found that these rare conditions can happen in some setups
and that a log-error would be better than an abort.
* Backport the upstream change to help the users affected by this issue.
[Test Case]
* Sadly we have no well isolated testcase yet, but an awesome and
responsive bug reporter who has a setup that usually triggered it a few
times over 1-2 weeks. Gladly the fix converts a former assert-abort
into a log warning. Therefore once we can check these logs and once the
messages appear know that the bug "would have happened but got fixed.
[Regression Potential]
* The change only is on a path that formerly was causing an abort of the
daemon. There a conversion of this assert to a log-warning should only
affect people that formerly had it crashing - and for them it is a fix.
Other use-cases should be unaffected.
Trying to think of regressions I can only come to e.g. CI-testcases
which expect fails on this case but now would work. Yet it would do so
as well with newer versions of bind as this is no Ubuntu Delta but a
backport.
* [racb] Changing an abort() to log and continue instead might leave the process in a bad state leading to a future unexplained crash, loss of data or even a security vulnerability. In this case though the fix is cherry-picked from upstream so we assume that they are confident that it is safe. Nevertheless, if there is a regression, I think that this is what's likely to happen, originally triggered "when the resolver is qname minimizing and forwarding at the same time".
[Other Info]
* n/a
---
I'm running Ubuntu 20.04 and bind9 1:9.16.1-0ubuntu2.3.
BIND sometimes crashes with:
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:12 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1001#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:13 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.0.0.1#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:14 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 2606:4700:4700::1111#53
Sep 23 10:10:15 <hostname> named[1146]: timed out resolving 'www.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: timed out resolving 'ssc.independent.co.uk/TYPE65/IN': 1.1.1.1#53
Sep 23 10:10:16 <hostname> named[1146]: resolver.c:5105: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
Sep 23 10:10:16 <hostname> named[1146]: #0 0x558b762dce43 in ??
Sep 23 10:10:16 <hostname> named[1146]: #1 0x7f390cf32ac0 in ??
Sep 23 10:10:16 <hostname> named[1146]: #2 0x7f390d0fb12d in ??
Sep 23 10:10:16 <hostname> named[1146]: #3 0x7f390d0fe940 in ??
Sep 23 10:10:16 <hostname> named[1146]: #4 0x7f390d104888 in ??
Sep 23 10:10:16 <hostname> named[1146]: #5 0x7f390d108f21 in ??
Sep 23 10:10:16 <hostname> named[1146]: #6 0x7f390d109a66 in ??
Sep 23 10:10:16 <hostname> named[1146]: #7 0x7f390d109ec6 in ??
Sep 23 10:10:16 <hostname> named[1146]: #8 0x7f390cf59fe1 in ??
Sep 23 10:10:16 <hostname> named[1146]: #9 0x7f390ca22609 in ??
Sep 23 10:10:16 <hostname> named[1146]: #10 0x7f390c943103 in ??
Sep 23 10:10:16 <hostname> named[1146]: exiting (due to assertion failure)
The crash has ocurred repeatedly on multiple hosts.
In all cases I observed BIND has logged timeouts immediately before each crash. |
|
| 2020-10-14 15:14:03 |
Robie Basak |
bind9 (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2020-10-14 15:14:04 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-10-14 15:14:05 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2020-10-14 15:14:09 |
Robie Basak |
tags |
focal server-next |
focal server-next verification-needed verification-needed-focal |
|
| 2020-10-23 12:10:34 |
Adrian Cunnelly |
bug |
|
|
added subscriber Adrian Cunnelly |
| 2020-10-25 16:35:18 |
Marian Rainer-Harbach |
tags |
focal server-next verification-needed verification-needed-focal |
focal server-next verification-done-focal verification-needed |
|
| 2020-10-26 06:37:51 |
Christian Ehrhardt |
tags |
focal server-next verification-done-focal verification-needed |
focal server-next verification-done verification-done-focal |
|
| 2020-10-26 09:54:27 |
Launchpad Janitor |
bind9 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-10-26 09:54:33 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
