This bug was fixed in the package bind9 - 1:9.10.3.dfsg.P4-8ubuntu1.15
---------------
bind9 (1:9.10.3.dfsg.P4-8ubuntu1.15) xenial; urgency=medium
* d/p/ubuntu//lp-1833400*: fix race on shutdown (LP: #1833400)
* d/p/fix-shutdown-race.diff: dig/host/nslookup could crash when interrupted
close to a query timeout (LP: #1797926)
-- Christian Ehrhardt <christian.ehrha...@canonical.com> Mon, 05 Aug
2019 07:30:49 +0200
** Changed in: bind9 (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1833400
Title:
named crashes on REQUIRE((disp->attributes assert
Status in bind9 package in Ubuntu:
Fix Released
Status in bind9 source package in Xenial:
Fix Released
Bug description:
[Impact]
* A race in the handling of the dispatcher can trigger a crash.
The reason is an assertion of a case that can actually happen (rarely
but it can)
* The fix is very small and essentially converts the assert into an early
return here a quote of the added comment:
If the attribute DNS_DISPATCHATTR_NOLISTEN is not set, then
the dispatch is already handling a recv; return immediately.
[Test Case]
* That is the hardest part on this SRU, this is a race and neither in the
upstream bug [1] nor here someone was able to come up with clear repro
steps. I'm afraid we might just review code and probably keep it in
proposed some extra time?
[Regression Potential]
* The change is minimal and upstream (as well as in Ubuntu releases) for
quite some time now. So I'm confident it isn't entirely broken.
The old code was preventing an odd condition to happen, the new code
still does only instead of an aborting assert it now is an early
return.
The regressions I could think of are only theoretical - like someone
having a test for this and now wondering it works - not really an
issue. No really the only issue I can think of is if that early return
on the return path would trigger a bug as it e.g. can't handle the
returned null properly. But TBH that would replace one crash (the
current one) with another one, so it isn't that bad.
[Other Info]
* This isn't very frequent at least to the crash DB [2] (others are :-/)
but at least this one has a clearly outlined solution.
[1]: https://bugs.isc.org/Public/Bug/Display.html?id=43822
[2]:
https://errors.ubuntu.com/?release=Ubuntu%2016.04&package=bind9&from=2016-01-01&to=2019-07-31
---
Ubuntu xenial 16.04, bind9 1:9.10.3.dfsg.P4-8ubuntu1.14
Yesterday the named process started crashing frequently, 49 crashes so
far on 49 different servers around the world (one crash each!). We did
run OS upgrades yesterday, but bind9 packages were not updated at this
time. This particular bind9 package version was mostly deployed out
last month. Due to the sudden surge of crashes and the distribution
I'm suspecting this might be triggered remotely by an incoming packet.
Backtrace from the assert:
2019-06-18T21:42:16.801421+00:00 hostname named[888]: general: critical:
../../../lib/dns/dispatch.c:3691: REQUIRE((disp->attributes & 0x00000020U) !=
0) failed, back trace
2019-06-18T21:42:16.801890+00:00 hostname named[888]: general: critical: #0
0x555c41aeeaf0 in ??
2019-06-18T21:42:16.802118+00:00 hostname named[888]: general: critical: #1
0x7f475bd66eaa in ??
2019-06-18T21:42:16.802315+00:00 hostname named[888]: general: critical: #2
0x7f475ca9f7da in ??
2019-06-18T21:42:16.802496+00:00 hostname named[888]: general: critical: #3
0x555c41ae3195 in ??
2019-06-18T21:42:16.802684+00:00 hostname named[888]: general: critical: #4
0x7f475bd8b420 in ??
2019-06-18T21:42:16.802875+00:00 hostname named[888]: general: critical: #5
0x7f475b7346ba in ??
2019-06-18T21:42:16.803056+00:00 hostname named[888]: general: critical: #6
0x7f475ae7e41d in ??
2019-06-18T21:42:16.803245+00:00 hostname named[888]: general: critical:
exiting (due to assertion failure)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1833400/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
