bind 9.8.1-P1 crashes with an assertion failure

Bug #1085593 reported by Alexander Gurvitz
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
bind9 (Ubuntu)
Fix Released
High
Unassigned
Precise
Won't Fix
Undecided
Unassigned

Bug Description

Ubuntu 12.04.1 LTS
1:9.8.1.dfsg.P1-4ubuntu0.4

While loading a certain zone file (attached) and using auto-dnssec (see the conf below), bind crashes with an "assertion failure" message. This bug seems to be fixed in the latest ISC releases - 9.8.4 and 9.9.2, please backport the patch.

(The attached zone file is not exactly correct, but should not result in an assertion failure).

named.conf:
zone net-me.net {
    type master;
    file "db";
    allow-update {127.0.0.1;};
    auto-dnssec allow;
};

Error log:
....
02-Dec-2012 11:54:14.815 rdata.c:393: REQUIRE(((rdata)->data == ((void *)0) && (rdata)->length == 0 && (rdata)->rdclass == 0 && (rdata)->type == 0 && (rdata)->flags == 0 && !((void *)(((rdata))->link.prev) != (void *)(-1)))) failed, back trace
02-Dec-2012 11:54:14.815 #0 0xb76b8e18 in ??
02-Dec-2012 11:54:14.815 #1 0xb74136c4 in ??
02-Dec-2012 11:54:14.815 #2 0xb753fec4 in ??
02-Dec-2012 11:54:14.815 #3 0xb751bb0f in ??
02-Dec-2012 11:54:14.815 #4 0xb7569174 in ??
02-Dec-2012 11:54:14.815 #5 0xb75c0662 in ??
02-Dec-2012 11:54:14.815 #6 0xb75d30db in ??
02-Dec-2012 11:54:14.815 #7 0xb75d84f9 in ??
02-Dec-2012 11:54:14.815 #8 0xb74369ac in ??
02-Dec-2012 11:54:14.816 #9 0xb73e9d4c in ??
02-Dec-2012 11:54:14.816 #10 0xb71dad3e in ??
02-Dec-2012 11:54:14.816 exiting (due to assertion failure)
Aborted (core dumped)

Revision history for this message
Alexander Gurvitz (0k53dmx9cig8cqkasqs0vqz-alex-f830mk0e7z07dk74sm41k1n) wrote :
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Reproduced on 1:9.8.1.dfsg.P1-4ubuntu0.4 (Precise).

On Raring, it doesn't crash, but I do get significant (>90%) constant CPU use with the following:

Dec 3 08:39:11 raring1 named[2561]: dns_dnssec_findzonekeys2: error reading private key file net-me.net/RSASHA256/17557: file not found
Dec 3 08:39:11 named[2561]: last message repeated 199 times
Dec 3 08:39:11 raring1 rsyslogd-2177: imuxsock begins to drop messages from pid 2561 due to rate-limiting
Dec 3 08:39:17 raring1 rsyslogd-2177: imuxsock lost 46730 messages from pid 2561 due to rate-limiting

You said that the zone file is not correct. Is this because it is malformed and that bind would be expected to reject it, or for some other reason? Does this bug affect correct zone files or just misconfigured ones?

Changed in bind9 (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Robie Basak (racb) wrote :

(Raring CPU hog on 1:9.8.4.dfsg-1ubuntu1)

Revision history for this message
Alexander Gurvitz (0k53dmx9cig8cqkasqs0vqz-alex-f830mk0e7z07dk74sm41k1n) wrote :

I first experienced with bug with a normal ("correct") zone file. Just the zone contained users information which I'm not willing to publish, thus I deleted most of the zone file and edited the rest and now it contains RRSIG records with "wrong" hashes, I don't this "malforming" affects anything - I suppose bind supposed to load the zone, and certainly bind should load the original zone file (which I can't share) yet it fails with the same message.

Mark Andrwes from ISC answered my bug report - "Yes this is a known bug and yes it is fixed in the current releases." (I did not ask ISC about high CPU usage which is a _separate_ (and probably unrelated) issue).

Btw, why not to update precise&earlier to bind 9.8.4 (I also asked here: http://askubuntu.com/questions/224894/package-version-updates-policy)

Revision history for this message
Robie Basak (racb) wrote :

Thanks.

If this happens with valid zone files, it sounds like an important issue to me for a stable release. I can imagine scenarios where server serving a large number of zones could crash due to a single customer, or something like that. bind should not crash. So I'm marking this as Importance: High based on a "severe impact" justification.

I've answered your question about updating to 9.8.4 on askubuntu. If you'd like to volunteer to drive a micro release exception for bind, then please go ahead, but whichever way I think it'll be quicker and easier to resolve this particular issue with a traditional SRU. It would really help with this if you could identify the upstream commits that fixes this issue. And are you able to link to your conversation with upstream, please?

Changed in bind9 (Ubuntu):
importance: Medium → High
Revision history for this message
Alexander Gurvitz (0k53dmx9cig8cqkasqs0vqz-alex-f830mk0e7z07dk74sm41k1n) wrote :

My conversation with upstream:
*My bug report sent to ISC:*

Attached is a named.conf and the zone file which result in assertion failure with bind 9.8.1 (actually BIND 9.8.1-P1 on ubuntu 12.04.01).
Bug does NOT appears in 9.8.4 nor in 9.9.2 so I guess it's fixed, though I can't find anything related in the changelog. Maybe you can help me pointing out which patch ubuntu maintainers should backport to make this fixed ?
...

*ISC answer*

We discourage cherry picking of maintenance fixes even for our paying support customers. We move them on to the latest maintenance checkout point/release on the branch they are using when they encounter a bug. This means they avoid discovering all the other bugs that have been fixed on the maintenance release. When you cherry pick fixes you then have to ensure that there are no dependancies on other fixes, etc.

Yes this is a known bug and yes it is fixed in the current releases.
Mark Andrews, ISC

Revision history for this message
Alexander Gurvitz (0k53dmx9cig8cqkasqs0vqz-alex-f830mk0e7z07dk74sm41k1n) wrote :

As for the exact commit - I myself can't find anything related in the changes history.

Revision history for this message
Robie Basak (racb) wrote :

"We move them on to the latest maintenance checkout point/release on the branch they are using *when* they encounter a bug."

Emphasis mine. Although I'm not saying that this is necessarily a problem for Ubuntu to have a micro release exception here, it is interesting that ISC advise their customers to update only when they have an issue. On Ubuntu, if we pushed the bind9 bugfix branch to -updates, Ubuntu users would get an update whether they have an issue or not, and thus could be affected by a regression even if this bug had nothing to do with them. I think this is a key difference when considering the stability/benefits of the two options.

I'm not sure that this bug is going to make much progress without a developer working out what to cherry-pick, which with the current process is what needs to happen. If upstream can't help, then somebody else will need to pick this up. Can you volunteer? I'm not sure I can justify spending lots of time on this bug unless it affects significantly many more people (there's an "affects me" link at the top of this bug).

If you want to change the process for bind9 by pushing for a standing micro release exception, probably the best place to begin discussing that would be the ubuntu-devel mailing list. My biggest concern would be around who would do both the initial work and maintenance of that, but I am a member of neither the stable release update team nor the technical board; perhaps they would be fine with it or have other concerns.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bind9 (Ubuntu Precise):
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in bind9 (Ubuntu Precise):
status: Confirmed → Won't Fix
Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Couldn't reproduce this on Jammy.

Changed in bind9 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.