Bug#1007945: bind9: assertion error about 13 seconds after security upgrade

[CJ Fearnley]

Package: bind9
Version: 1:9.10.3.dfsg.P4-12.3+deb9u10
Severity: important

Dear Maintainer,

I applied today's bind9 security upgrade on my long stable DNS server
and about 13 seconds later I see the following in my logs:

Mar 19 00:10:40 jitterbug named[3492]: ../../../lib/dns/name.c:2487: REQUIRE((((dest) != ((void *)0)) && (((const isc__magic_t *)(dest))->magic == ((('D') << 24 | ('N') << 16 | ('S') << 8 | ('n')))))) failed, back trace
Mar 19 00:10:40 jitterbug named[3492]: #0 0x484457 in ??
Mar 19 00:10:40 jitterbug named[3492]: #1 0xb79407c5 in ??
Mar 19 00:10:40 jitterbug named[3492]: #2 0xb7ddbd02 in ??
Mar 19 00:10:40 jitterbug named[3492]: #3 0xb7e5dd1c in ??
Mar 19 00:10:40 jitterbug named[3492]: #4 0xb7e601df in ??
Mar 19 00:10:40 jitterbug named[3492]: #5 0xb7e60a3b in ??
Mar 19 00:10:40 jitterbug named[3492]: #6 0xb7965f04 in ??
Mar 19 00:10:40 jitterbug named[3492]: #7 0xb790e27a in ??
Mar 19 00:10:40 jitterbug named[3492]: #8 0xb75d0366 in ??
Mar 19 00:10:40 jitterbug named[3492]: exiting (due to assertion failure)
Mar 19 00:10:40 jitterbug systemd[1]: bind9.service: Main process exited, code=killed, status=6/ABRT
Mar 19 00:10:40 jitterbug rndc[3544]: rndc: connect failed: 127.0.0.1#953: connection refused
Mar 19 00:10:40 jitterbug systemd[1]: bind9.service: Control process exited, code=exited status=1
Mar 19 00:10:40 jitterbug systemd[1]: bind9.service: Unit entered failed state.
Mar 19 00:10:40 jitterbug systemd[1]: bind9.service: Failed with result 'signal'.

After attempting to stop/start or restart several times, I decided to
downgrade and bind9 is stable once again.

I applied the bind9 security upgrade on several other systems. I
have not noticed a problem on any of them (some LTS, some Buster,
some Bullseye). So it must be something in my complex environment that
triggers a bug that doesn't affect most environments.

-- System Information:
Debian Release: 9.13
APT prefers oldoldstable
APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-0.bpo.19-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
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+deb9u10
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+deb9u10
ii libc6 2.24-11+deb9u4
ii libcap2 1:2.25-1
ii libcomerr2 1.43.4-2+deb9u2
ii libdns162 1:9.10.3.dfsg.P4-12.3+deb9u10
ii libgeoip1 1.6.9-4
ii libgssapi-krb5-2 1.15-1+deb9u3
ii libirs141 1:9.10.3.dfsg.P4-12.3+deb9u11
ii libisc160 1:9.10.3.dfsg.P4-12.3+deb9u10
ii libisccc140 1:9.10.3.dfsg.P4-12.3+deb9u10
ii libisccfg140 1:9.10.3.dfsg.P4-12.3+deb9u10
ii libk5crypto3 1.15-1+deb9u3
ii libkrb5-3 1.15-1+deb9u3
ii liblwres141 1:9.10.3.dfsg.P4-12.3+deb9u10
ii libssl1.0.2 1.0.2u-1~deb9u7
ii libxml2 2.9.4+dfsg1-2.2+deb9u5
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+deb9u10
pn resolvconf <none>
pn ufw <none>

-- Configuration Files:
/etc/bind/db.root changed [not included]
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]

-- debconf information excluded

[Thorsten]

I have the same bug since the security update tonight.

Specifically, this assertion fails:

../../../lib/dns/name.c:2487: REQUIRE((((dest) != ((void *)0)) && (((const isc__magic_t *)(dest))->magic == ((('D') << 24 | ('N') << 16 | ('S') << 8 | ('n')))))) failed, back trace

Can anyone give me a hint how to downgrade bind9 ?

[Markus Koschany]

Am Samstag, dem 19.03.2022 um 10:55 +0100 schrieb Christopher Huhn:
> Hi y'all
>
> It looks like the bind9 security update for Stretch is severely broken,
> cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007945
>
> We had to emergency downgrade to get our DNS servers working again.

Thanks for the report. I have found the reason for the regression and I will
release an update shortly.

Regards,

Markus