** Description changed: [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. + * 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 + * 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. + * 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. + * 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 + + * 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896740 Title: BIND crashes with failed assertion INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1896740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
