ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-07-16T06:54:50Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2009Update ISC logo in documentation2020-07-16T06:54:50ZMark AndrewsUpdate ISC logo in documentationAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2006Coverity reports CHECKED_RETURN defects in keymgr2020-07-15T06:27:32ZMatthijs Mekkingmatthijs@isc.orgCoverity reports CHECKED_RETURN defects in keymgr```
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 304937: (CHECKED_RETURN)
/lib/dns/keymgr.c: 2004 in dns_keymgr_status()
/lib/dns/keymgr.c: 2005 in dns_keymgr_status()
__________________________________...```
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 304937: (CHECKED_RETURN)
/lib/dns/keymgr.c: 2004 in dns_keymgr_status()
/lib/dns/keymgr.c: 2005 in dns_keymgr_status()
________________________________________________________________________________________________________
*** CID 304937: (CHECKED_RETURN)
/lib/dns/keymgr.c: 2004 in dns_keymgr_status()
1998
1999 if (dst_key_is_unused(dkey->key)) {
2000 continue;
2001 }
2002
2003 // key data
>>> CID 304937: (CHECKED_RETURN)
>>> Calling "dst_key_getbool" without checking return value (as is done elsewhere 25 out of 29 times).
2004 dst_key_getbool(dkey->key, DST_BOOL_KSK, &ksk);
2005 dst_key_getbool(dkey->key, DST_BOOL_ZSK, &zsk);
2006 dns_secalg_format((dns_secalg_t)dst_key_alg(dkey->key), algstr,
2007 sizeof(algstr));
2008 isc_buffer_printf(&buf, "\nkey: %d (%s), %s\n",
2009 dst_key_id(dkey->key), algstr,
/lib/dns/keymgr.c: 2005 in dns_keymgr_status()
1999 if (dst_key_is_unused(dkey->key)) {
2000 continue;
2001 }
2002
2003 // key data
2004 dst_key_getbool(dkey->key, DST_BOOL_KSK, &ksk);
>>> CID 304937: (CHECKED_RETURN)
>>> Calling "dst_key_getbool" without checking return value (as is done elsewhere 25 out of 29 times).
2005 dst_key_getbool(dkey->key, DST_BOOL_ZSK, &zsk);
2006 dns_secalg_format((dns_secalg_t)dst_key_alg(dkey->key), algstr,
2007 sizeof(algstr));
2008 isc_buffer_printf(&buf, "\nkey: %d (%s), %s\n",
2009 dst_key_id(dkey->key), algstr,
2010 keymgr_keyrole(dkey->key));
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2005Coverity is reporting double unlock.2020-07-16T07:29:44ZMark AndrewsCoverity is reporting double unlock.```
3159
10. Condition readable, taking true branch.
11. Condition !!(readable || writeable), taking true branch.
3160 REQUIRE(readable || writeable);
12. Condition readable, taking true branch.
3161 if (read...```
3159
10. Condition readable, taking true branch.
11. Condition !!(readable || writeable), taking true branch.
3160 REQUIRE(readable || writeable);
12. Condition readable, taking true branch.
3161 if (readable) {
13. Condition sock->listener, taking true branch.
3162 if (sock->listener) {
14. unlock: internal_accept unlocks sock->lock. [show details]
3163 internal_accept(sock);
15. Falling through to end of if statement.
3164 } else {
3165 internal_recv(sock);
3166 }
3167 }
3168
16. Condition writeable, taking true branch.
3169 if (writeable) {
17. Condition sock->connecting, taking false branch.
3170 if (sock->connecting) {
3171 internal_connect(sock);
3172 } else {
CID 303441 (#1-2 of 2): Double unlock (LOCK)
18. double_unlock: internal_send unlocks sock->lock while it is unlocked. [show details]
3173 internal_send(sock);
3174 }
3175 }
3176
3177 /* sock->lock is unlocked in internal_* function */
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2003Remove redundant listener != NULL check2020-07-16T06:53:46ZMark AndrewsRemove redundant listener != NULL checkWith isc_mem_get no longer failing this check is no longer needed.
```
1258 } else {
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null...With isc_mem_get no longer failing this check is no longer needed.
```
1258 } else {
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1259 if (listener != NULL) {
1260 listener->exiting = true;
1261 free_listener(listener);
1262 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1997[CVE-2020-8621] Attempting QNAME minimization after forwarding can lead to an...2020-09-11T09:02:40ZOndřej Surý[CVE-2020-8621] Attempting QNAME minimization after forwarding can lead to an assertion failure in resolver.c### Summary
Similar to issue 1219, I am getting repeated periodic bind crashes. I am on Ubuntu Server 20.04 LTS, fully patched and up to date. This is installed from the ISC Bind9 PPA using the focal release.
### BIND version used
``...### Summary
Similar to issue 1219, I am getting repeated periodic bind crashes. I am on Ubuntu Server 20.04 LTS, fully patched and up to date. This is installed from the ISC Bind9 PPA using the focal release.
### BIND version used
```
BIND 9.16.4-Ubuntu (Stable Release) <id:0849b42>
running on Linux x86_64 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64
-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads'
'--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-libjson-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=
no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-cWwckC/bind9-9.16.4=. -fstack-protector-strong -Wformat -
Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Not sure, named is running fine and suddenly I will notice resolving slows on clients as DNS reverts to the secondary resolver, upon checking the service status it is "failed" in systemd. The service restarts but then crashes intermittently, approximately every 1-3 days.
### What is the current *bug* behavior?
Service fails and resolving stops.
### What is the expected *correct* behavior?
Service should not fail/stop
### Relevant configuration files
```
root@HOST:~# named-checkconf -px
...
```
[Sanitized by @mnowak.]
### Relevant logs and/or screenshots
Console output of /var/log/bind/bind.log
```
30-Jun-2020 00:00:02.536 general: notice: all zones loaded
30-Jun-2020 00:00:02.536 general: notice: running
30-Jun-2020 10:19:36.354 general: critical: resolver.c:5104: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
30-Jun-2020 10:19:36.354 general: critical: #0 0x55b9b83ff083 in ??
30-Jun-2020 10:19:36.354 general: critical: #1 0x7f4ea095cac0 in ??
30-Jun-2020 10:19:36.354 general: critical: #2 0x7f4ea0b26675 in ??
30-Jun-2020 10:19:36.354 general: critical: #3 0x7f4ea0b29e90 in ??
30-Jun-2020 10:19:36.354 general: critical: #4 0x7f4ea0b2fdb8 in ??
30-Jun-2020 10:19:36.354 general: critical: #5 0x7f4ea0b348a1 in ??
30-Jun-2020 10:19:36.354 general: critical: #6 0x7f4ea0984d51 in ??
30-Jun-2020 10:19:36.354 general: critical: #7 0x7f4ea0425609 in ??
30-Jun-2020 10:19:36.354 general: critical: #8 0x7f4ea034c103 in ??
30-Jun-2020 10:19:36.354 general: critical: exiting (due to assertion failure)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1996[CVE-2020-8620]: A specially crafted large TCP payload can trigger an asserti...2023-03-21T13:42:51ZOndřej Surý[CVE-2020-8620]: A specially crafted large TCP payload can trigger an assertion failure in tcpdns.cNone (published patch date)
TALOS-2020-1100
CVE-2020-8620
Internet Systems Consortium's BIND TCP Receive Buffer Length Assertion Check Denial of Service Vulnerability
### Summary
An assertion failure exists within the Internet Sy...None (published patch date)
TALOS-2020-1100
CVE-2020-8620
Internet Systems Consortium's BIND TCP Receive Buffer Length Assertion Check Denial of Service Vulnerability
### Summary
An assertion failure exists within the Internet Systems Consortium's BIND server versions 9.16.1 through 9.17.1 when processing TCP traffic via the libuv library. Due to a length specified within a callback for the library, flooding the server's TCP port used for larger DNS requests (AXFR) can cause the libuv library to pass a length to the server which will violate an assertion check in the server's verifications. This assertion check will terminate the service resulting in a denial of service condition. An attacker can flood the port with unauthenticated packets in order to trigger this vulnerability.
### Tested Versions
Internet Systems Consortium BIND 9.16.1
Internet Systems Consortium BIND 9.16.2
Internet Systems Consortium BIND 9.16.3
Internet Systems Consortium BIND 9.17.0
Internet Systems Consortium BIND 9.17.1
### Product URLs
[https://www.isc.org/bind](https://www.isc.org/bind)
### CVSSv3 Score
7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
### CWE
CWE-617 - Reachable Assertion
### Details
The BIND nameserver is considered the reference implementation of the Domain Name System of the Internet. It is capable of being an authoritative name server as well as a recursive cache for domain name queries on a network.
The BIND nameserver is based on a custom event queueing system that wraps around the `libuv` library (http://libuv.org) for performing asynchronous I/O as needed by the server. The `libuv` library was introduced as a new network manager during the release of version 9.16 in order to allow the server to be used on both the Posix and Windows environments and to simplify the management of processing network I/O distributed amongst a configurable number of threads within the server.
The BIND nameserver combines its own queue for scheduling with the `libuv` library in order to process requests and queries asynchronously for both the UDP and TCP protocols. In order to accomplish this, the server must first initialize the `libuv` library by allocating and initializing the `uv_loop_t` which is a handle directly used by the library to manage the event loop used by the server. After the server has initialized its core memory handling functions in the setup phase of the daemon, the `isc_nm_start` function will be used to construct a `uv_loop_t` for a number of workers using the `uv_loop_init` function at [1]. After initializing the loop that is to be used for each worker, the server will then allocate space for a receive buffer at [2] and then assign it into the context of the worker. This loop is then used to bind to the configured UDP and TCP ports as used by the server.
```
lib/isc/netmgr/netmgr.c:142
isc_nm_t *
isc_nm_start(isc_mem_t *mctx, uint32_t workers) {
isc_nm_t *mgr = NULL;
char name[32];
mgr = isc_mem_get(mctx, sizeof(*mgr));
*mgr = (isc_nm_t){ .nworkers = workers };
isc_mem_attach(mctx, &mgr->mctx);
...
r = uv_loop_init(&worker->loop); // [1] Initialize a uv_loop_t for each worker
RUNTIME_CHECK(r == 0);
...
r = uv_async_init(&worker->loop, &worker->async, async_cb);
RUNTIME_CHECK(r == 0);
...
worker->ievents = isc_queue_new(mgr->mctx, 128);
worker->ievents_prio = isc_queue_new(mgr->mctx, 128);
worker->recvbuf = isc_mem_get(mctx, ISC_NETMGR_RECVBUF_SIZE); // [2] Allocate a receive buffer of the size ISC_NETMGR_RECVBUF_SIZE
...
```
After the server has initialized each worker and bound to the configured ports, the server must use `libuv` to assign a callback to dispatch to when receiving a connection on a port. The callback that is used for processing TCP is the following `dnslisten_acceptcb` function. After performing a few validations, at [3] the function will call the `isc_nm_read` function with a callback, `dnslisten_readcb`, as its second parameter. This callback will be stored into a structure and then later passed to `libuv` in order to inform the library what to call when the server needs to read data from a connected TCP client.
```
lib/isc/netmgr/tcpdns.c:98
/*
* Accept callback for TCP-DNS connection.
*/
static void
dnslisten_acceptcb(isc_nmhandle_t *handle, isc_result_t result, void *cbarg) {
isc_nmsocket_t *dnslistensock = (isc_nmsocket_t *)cbarg;
isc_nmsocket_t *dnssock = NULL;
REQUIRE(VALID_NMSOCK(dnslistensock));
REQUIRE(dnslistensock->type == isc_nm_tcpdnslistener);
/* If accept() was unnsuccessful we can't do anything */
if (result != ISC_R_SUCCESS) {
return;
}
...
isc_nm_read(handle, dnslisten_readcb, dnssock); // [3] Pass the dnslisten_readcb callback for reading as a parameter
```
Inside the `isc_nm_read` function, the server will then assign the `dnslisten_readcb` callback that was passed as its second parameter into a `isc_nmsocket_t` structure at [4] as `sock->rcb.recv`. After preparing the `isc_nmsocket_t` structure, the server will fetch a new event and then assign the `isc_nmsocket_t` into it. Eventually at [5], the function will pass the event as the second parameter to the `isc__nm_async_startread` function. The `isc__nm_async_startread` function is directly responsible for calling into the `libuv` library with the necessary callbacks in order for the server to process any received DNS packets.
```
lib/isc/netmgr/tcp.c:521
isc_result_t
isc_nm_read(isc_nmhandle_t *handle, isc_nm_recv_cb_t cb, void *cbarg) {
isc_nmsocket_t *sock = NULL;
isc__netievent_startread_t *ievent = NULL;
...
sock = handle->sock;
sock->rcb.recv = cb; // [4] Store callback into sock
sock->rcbarg = cbarg;
...
ievent = isc__nm_get_ievent(sock->mgr, netievent_tcpstartread);
ievent->sock = sock; // Assign sock into the event
if (sock->tid == isc_nm_tid()) {
isc__nm_async_startread(&sock->mgr->workers[sock->tid], // [5] Pass the event containing the callback as the second parameter
(isc__netievent_t *)ievent);
isc__nm_put_ievent(sock->mgr, ievent);
} else {
...
return (ISC_R_SUCCESS);
}
```
Once inside the `isc__nm_async_startread` function, the `isc_nmsocket_t` will then be extracted from a field belonging to the event. After starting a timer with `libuv` in order to determine when to timeout the connection, the server will execute the `uv_read_start` function at [6]. The `uv_read_start` function belongs to `libuv` and is used in order to inform the library which callbacks to use when allocating space for the receive buffer during processing of a TCP stream and which callback to actually use for processing the data from the buffer that was received. The vulnerability referred to by this document is specifically due to the way these two callbacks are implemented by the server.
```
lib/isc/netmgr/tcp.c:548
void
isc__nm_async_startread(isc__networker_t *worker, isc__netievent_t *ev0) {
isc__netievent_startread_t *ievent = (isc__netievent_startread_t *)ev0;
isc_nmsocket_t *sock = ievent->sock;
int r;
...
r = uv_read_start(&sock->uv_handle.stream, isc__nm_alloc_cb, read_cb); // [6] Use libuv to assign callbacks for reading
...
}
```
When the `libuv` library needs the server to allocate a buffer to receive packet data into, it will call the following function. This function's responsibility is to allocate a buffer to receive packet data into, and then write the buffer along with its length into one of the function's parameters. The `libuv` library provides the `uv_buf_t` object to modify and a suggested size in its arguments. The implementation chosen by the server was to preallocate the read buffer for each worker during the setup process of the worker. Therefore in this function, the server will only need to assign the preallocated buffer and its size at [7] which prevents needing to allocate during the receiving of a packet.
```
lib/isc/netmgr/netmgr.c:972
void
isc__nm_alloc_cb(uv_handle_t *handle, size_t size, uv_buf_t *buf) {
isc_nmsocket_t *sock = uv_handle_get_data(handle);
isc__networker_t *worker = NULL;
REQUIRE(VALID_NMSOCK(sock));
REQUIRE(isc__nm_in_netthread());
REQUIRE(size <= ISC_NETMGR_RECVBUF_SIZE);
worker = &sock->mgr->workers[sock->tid];
INSIST(!worker->recvbuf_inuse);
buf->base = worker->recvbuf; // [7] Assign worker's receive buffer into buf->base
worker->recvbuf_inuse = true;
buf->len = ISC_NETMGR_RECVBUF_SIZE; // [7] Assign the length for the worker's receive buffer.
}
```
The size that was used for the allocation of the receive buffer and is assigned to the buffer length for `libuv` to use is defined in the following file. As described in the comments, this length is taken from the `libuv` source and contains the maximum size of a message on Posix platforms. Due to a smaller buffer size being used for the Windows platforms, the vulnerability described by this document does not affect that class of particular platforms.
```
lib/isc/netmgr/netmgr-int.h:38
#if !defined(WIN32)
/*
* New versions of libuv support recvmmsg on unices.
* Since recvbuf is only allocated per worker allocating a bigger one is not
* that wasteful.
* 20 here is UV__MMSG_MAXWIDTH taken from the current libuv source, nothing
* will break if the original value changes.
*/
#define ISC_NETMGR_RECVBUF_SIZE (20 * 65536)
#else
#define ISC_NETMGR_RECVBUF_SIZE (65536)
#endif
```
After the `libuv` library has dispatched to the allocation callback in order to allocate a buffer to read packet data into, the library can now execute the callback that is responsible for processing the actual data from the packet. The server implements this with the following `read_cb` function. This function will simply take the `uv_buf_t` and length that is passed as parameters to assign them into an `isc_region_t` at [8]. After initializing the `isc_region_t`, the server will then dispatch to the `dnslisten_readcb` callback at [9] that was previously assigned in the `isc_nm_read` function.
```
lib/isc/netmgr/tcp.c:639
static void
read_cb(uv_stream_t *stream, ssize_t nread, const uv_buf_t *buf) {
isc_nmsocket_t *sock = uv_handle_get_data((uv_handle_t *)stream);
REQUIRE(VALID_NMSOCK(sock));
REQUIRE(buf != NULL);
if (nread >= 0) {
isc_region_t region = { .base = (unsigned char *)buf->base, // [8] Initialize the isc_region_t with the buffer and size from libuv
.length = nread };
if (sock->rcb.recv != NULL) {
sock->rcb.recv(sock->tcphandle, ®ion, sock->rcbarg); // [9] Pass the region to the worker's callback
}
...
```
The `dnslisten_readcb` function has the responsibility for taking the packet data that was dispatched as a parameter by `libuv`, and aggregating it into a buffer containing a full DNS packet packet confirming to RFC1035. This is done by taking the packet data and its length from the `region` parameter of the type `isc_region_t` which was initialized by the calling function and using it to grow a buffer that will later be processed. At [10], the packet data and its length are extracted from the `isc_region_t` and assigned into local variables. Once determining the length, it is then used to check if the current packet buffer size that the server will process is large enough to fit the newly read data from the TCP socket. If the sum of the current buffer length and the number of bytes read from the packet is larger than the buffer size, then at [11] the server will use the `alloc_dnsbuf` function to reallocate the buffer to fit the calculated size. After performing the resize, at [12] the server will copy the new packet data from the `isc_region_t` directly into the current packet buffer and then process it at [13].
```
lib/isc/netmgr/tcpdns.c:198
static void
dnslisten_readcb(isc_nmhandle_t *handle, isc_region_t *region, void *arg) {
isc_nmsocket_t *dnssock = (isc_nmsocket_t *)arg;
unsigned char *base = NULL;
bool done = false;
size_t len;
...
base = region->base; // [10] Extract the libuv buffer and its length from the region
len = region->length;
if (dnssock->buf_len + len > dnssock->buf_size) {
alloc_dnsbuf(dnssock, dnssock->buf_len + len); // [11] Allocate the DNS buffer if it is too small
}
memmove(dnssock->buf + dnssock->buf_len, base, len); // [12] Copy new packet data to the end of the current packet buffer
dnssock->buf_len += len;
...
do {
isc_result_t result;
isc_nmhandle_t *dnshandle = NULL;
result = processbuffer(dnssock, &dnshandle); // [13] Process the contents off the packet data
...
```
When reallocating the packet buffer, the following `alloc_dnsbuf` function is used. The comment in front of this function indicates that the buffer size being defined for `NM_BIG_BUF` is for two full DNS packet lengths as this should be enough. However, due to the way that `libuv` works the length that was allocated for the worker receive buffer that was assigned in `isc__nm_alloc_cb` is used instead. This length is `20 * 64k` and is passed to the `read` system call by the `libuv` library. This results in the value of the `len` field that was passed to this function capable of being up to 0x140000 bytes. At [14], an assertion is used to validate that the length is less than the `NM_BIG_BUF` definition. If the length does not validate, then the assertion will log itself and follow up by calling the `abort` library function. This will directly terminate the server resulting in a denial of service condition.
```
lib/isc/netmgr/tcpdns.c:58
/*
* Two full DNS packets with lengths.
* netmgr receives 64k at most so there's no risk
* of overrun.
*/
#define NM_BIG_BUF (65535 + 2) * 2
static inline void
alloc_dnsbuf(isc_nmsocket_t *sock, size_t len) {
REQUIRE(len <= NM_BIG_BUF); // [14] Assertion
if (sock->buf == NULL) {
/* We don't have the buffer at all */
size_t alloc_len = len < NM_REG_BUF ? NM_REG_BUF : NM_BIG_BUF;
sock->buf = isc_mem_allocate(sock->mgr->mctx, alloc_len);
sock->buf_size = alloc_len;
} else {
/* We have the buffer but it's too small */
sock->buf = isc_mem_reallocate(sock->mgr->mctx, sock->buf,
NM_BIG_BUF);
sock->buf_size = NM_BIG_BUF;
}
}
```
### Crash Information
First we attach to the process, and then resume its execution.
```
$ gdb -p `pgrep named`
(gdb) c
Continuing.
```
After running the provided proof-of-concept, gdb will break due to the `SIGABRT` signal that was raised by the assertion.
```
(gdb)
Thread 5 "isc-net-0003" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f95a443a700 (LWP 7)]
0x00007f95a822a18b in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
```
The following backtrace is at the time of the signal being dispatched to the process.
```
(gdb) bt
#0 0x00007f95a822a18b in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f95a8209859 in abort () from target:/lib/x86_64-linux-gnu/libc.so.6
#2 0x0000563409bc75c6 in assertion_failed (file=0x563409f56eff "tcpdns.c", line=66, type=isc_assertiontype_require,
cond=0x563409f56ee8 "len <= (65535 + 2) * 2") at ./main.c:260
#3 0x0000563409e83070 in isc_assertion_failed (file=0x563409f56eff "tcpdns.c", line=66, type=isc_assertiontype_require,
cond=0x563409f56ee8 "len <= (65535 + 2) * 2") at assertions.c:46
#4 0x0000563409ea9453 in alloc_dnsbuf (sock=0x7f9598ce6be0, len=1310749) at tcpdns.c:66
#5 0x0000563409ea9d2a in dnslisten_readcb (handle=0x7f957c003180, region=0x7f95a44369b0, arg=0x7f9598ce6be0) at tcpdns.c:223
#6 0x0000563409ea696a in read_cb (stream=0x7f9598ce6920, nread=1310720, buf=0x7f95a4436a20) at tcp.c:651
#7 0x00007f95a841bad1 in ?? () from target:/lib/x86_64-linux-gnu/libuv.so.1
#8 0x00007f95a841c608 in ?? () from target:/lib/x86_64-linux-gnu/libuv.so.1
#9 0x00007f95a8421ab0 in uv.io_poll () from target:/lib/x86_64-linux-gnu/libuv.so.1
#10 0x00007f95a84117ac in uv_run () from target:/lib/x86_64-linux-gnu/libuv.so.1
#11 0x0000563409ea0bc2 in nm_thread (worker0=0x56340b6dd048) at netmgr.c:481
#12 0x00007f95a83e5609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007f95a8306103 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
```
In frame 5 belonging to the `dnslisten_readcb` function, we can see that the region length corresponds directly to the value defined for `ISC_NETMGR_RECVBUF_SIZE`.
```
(gdb) frame 5
#5 0x0000563409ea9d2a in dnslisten_readcb (handle=0x7f957c003180, region=0x7f95a44369b0, arg=0x7f9598ce6be0) at tcpdns.c:223
223 alloc_dnsbuf(dnssock, dnssock->buf_len + len);
(gdb) p *regio
$3 = {base = 0x7f95a443b010 "l", length = 1310720}
The current buffer size that is to be grown is only 0x20002 bytes.
(gdb) p dnssock.buf_size
$7 = 131074
(gdb) p dnssock.buf_len
$8 = 29
```
### Exploit Proof of Concept
To use the provided proof-of-concept, it must first be modified. Change both the DST_IP and DST_PORT variables to point to the host the BIND daemon is listening on, and then run it with Python 2.x.
### Mitigation
Flood protection could mitigate this denial of service if configured properly.
### Credit
Discovered by Emanuel Almeida of Cisco Systems, Inc..
https://talosintelligence.com/vulnerability_reports/
### Timeline
None - Vendor Disclosure
None - Public ReleaseAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1994netscope.c:23:50: error: unused parameter 'addr' when HAVE_IF_NAMETOINDEX und...2020-08-05T13:09:26ZMichal Nowaknetscope.c:23:50: error: unused parameter 'addr' when HAVE_IF_NAMETOINDEX undefined on illumosOn OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `main` commit 78a4ed31322271ff324994ab058b8448ae4a2252 fails in `lib/isc/netscope.c` with:
```
netscope.c: In function 'isc_netscope_pton':
netscope.c:23:50: error: unu...On OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `main` commit 78a4ed31322271ff324994ab058b8448ae4a2252 fails in `lib/isc/netscope.c` with:
```
netscope.c: In function 'isc_netscope_pton':
netscope.c:23:50: error: unused parameter 'addr' [-Werror=unused-parameter]
isc_netscope_pton(int af, char *scopename, void *addr, uint32_t *zoneid) {
^~~~
cc1: all warnings being treated as errors
```
It seems that `addr` is used only when `HAVE_IF_NAMETOINDEX` is defined.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1993check.c:1576:37: error: expected identifier before numeric constant on illumos2020-07-13T22:52:29ZMichal Nowakcheck.c:1576:37: error: expected identifier before numeric constant on illumosOn OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `v9_16` commit 38ca3fbcdc5c02e2f985d5ff8937d473b50d6aef fails in `lib/bind9/check.c` with:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/bind9/...On OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `v9_16` commit 38ca3fbcdc5c02e2f985d5ff8937d473b50d6aef fails in `lib/bind9/check.c` with:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/bind9/config.h -I/export/home/newman/bind9 -I../.. -I. -I/export/home/newman/bind9/lib/bind9/include -I../../lib/bind9/include -I/export/home/newman/bind9/lib/dns/include -I../../lib/dns/include -I/export/home/newman/bind9/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I/export/home/newman/bind9/lib/isccfg/include -I../../lib/isccfg/include -I/export/home/newman/bind9/lib/ns/include -I../../lib/ns/include -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -m64 -O3 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -Wshadow -Werror -c check.c -fPIC -DPIC -o .libs/check.o
In file included from /usr/include/sys/select.h:53:0,
from /usr/include/sys/types.h:640,
from /usr/include/sys/wait.h:37,
from /usr/include/stdlib.h:45,
from check.c:16:
check.c: In function 'check_options':
check.c:1576:37: error: expected identifier before numeric constant
enum { MAS = 1, PRI = 2, SLA = 4, SEC = 8 } values = 0;
^
gmake[2]: *** [Makefile:273: check.lo] Error 1
```
It turns out that `/usr/include/sys/time.h` has `SEC` [defined](https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/time.h#L242).
Renaming `SEC` to `SCN` in `lib/bind9/check.c` does the trick. The introduction of `SEC` was in dca3658720cfb7f40b75e418a87d85552fe2a09c.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1992Backport primaries and documentation changes to v9.162021-06-28T09:15:09ZOndřej SurýBackport primaries and documentation changes to v9.16* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1991Cleanup redundant non-NULL check.2020-07-06T00:30:57ZMark AndrewsCleanup redundant non-NULL check.```
1407 if (sigrdataset != NULL) {
1408 putrdataset(client->mctx, &sigrdataset);
1409 }
CID 288001 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking rctx suggest...```
1407 if (sigrdataset != NULL) {
1408 putrdataset(client->mctx, &sigrdataset);
1409 }
CID 288001 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking rctx suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1410 if (rctx != NULL) {
1411 isc_mutex_destroy(&rctx->lock);
1412 isc_mem_put(mctx, rctx, sizeof(*rctx));
1413 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1989'rndc dnstap --roll' with too big a argument (>128) can cause a buffer overflow.2020-08-04T11:14:51ZMark Andrews'rndc dnstap --roll' with too big a argument (>128) can cause a buffer overflow.```
1158 if (versions > 0) {
1159 /*
1160 * First we fill 'to_keep' structure using insertion sort
1161 */
5. index_parm: Indexing array of size 2048 with versions minus an offse...```
1158 if (versions > 0) {
1159 /*
1160 * First we fill 'to_keep' structure using insertion sort
1161 */
5. index_parm: Indexing array of size 2048 with versions minus an offset in call to memset. [Note: The source code implementation of the function has been overridden by a builtin model.]
1162 memset(to_keep, 0, versions * sizeof(long long));
1163 while (isc_dir_read(&dir) == ISC_R_SUCCESS) {
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1988bad output rndc dnssec -status on Windows2020-07-16T07:03:47ZMatthijs Mekkingmatthijs@isc.orgbad output rndc dnssec -status on WindowsThe following discussion from !3780 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3780#note_144605): (+1 comment)
> This looks fine to me, though I started a p...The following discussion from !3780 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3780#note_144605): (+1 comment)
> This looks fine to me, though I started a pipeline including Windows
> system tests that I would like to complete successfully before merging
> this MR:
>
> https://gitlab.isc.org/isc-projects/bind9/pipelines/45755August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1987Fix formatting error in man pages section of BIND ARM2020-07-01T21:47:50ZSuzanne GoldlustFix formatting error in man pages section of BIND ARMOne formatting error was missed the first time around.One formatting error was missed the first time around.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1977BIND 9.16 triggers build warnings on FreeBSD 11.42020-06-30T10:19:31ZMichał KępieńBIND 9.16 triggers build warnings on FreeBSD 11.4With Clang 10.0.0 on FreeBSD 11.4, compiling `lib/dns/spnego.c` triggers
the following warnings:
spnego.c:361:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
...With Clang 10.0.0 on FreeBSD 11.4, compiling `lib/dns/spnego.c` triggers
the following warnings:
spnego.c:361:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:366:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:371:12: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:376:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:380:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
5 errors generated.
For some reason, the `buster` build (which uses Clang 10.0.1) is happy
with this code as it is :shrug:
The prototype of `lib/dns/spnego.c:cmp_gss_type()` was changed back in
b105ccee68ccc3c18e6ea530063b3c8e5a42571c. `v9_11` is not affected
because !546 was not backported. `main` is not affected, either,
because 978c7b2e89aa37a7ddfe2f6b6ba12ce73dd04528 dropped
`lib/dns/spnego.c` altogether.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1976LMDB 0.9.26 will break "rndc reconfig" (+ other LMDB issues)2020-08-20T19:36:01ZMichał KępieńLMDB 0.9.26 will break "rndc reconfig" (+ other LMDB issues)The way BIND uses LMDB is at odds with what the authors of that library
expect and intend. ~~While I cannot find any mention of that
recommendation in the [docs][1], the LMDB author himself [says][2] that
"you should only ever open an e...The way BIND uses LMDB is at odds with what the authors of that library
expect and intend. ~~While I cannot find any mention of that
recommendation in the [docs][1], the LMDB author himself [says][2] that
"you should only ever open an environment once in any particular
process".~~[^1] BIND calls `mdb_env_open()` and `mdb_env_close()`
[multiple][3] [times][4] within the lifetime of a single process, but
AFAICT, doing that in an "open → close → open → close → ..." type of
sequence works just fine. Unfortunately, BIND does something worse and
it is related to what happens during an `rndc reconfig`: new views are
configured first and only after that happens, the old views get torn
down. For LMDB, this means that we call `mdb_env_open()` for a
previously `mdb_env_open()`ed LMDB environment *from the same process*
and then close the old "instance" of the environment. I am not sure we
ever cared about this a lot because it seemed to Just Work™. It did
[bite us][5] once (see 40a90fbf89738c1aa867a5f09ef7243ef3ae52e4), but we
worked around the problem and moved on.
Still, the [docs][6] clearly state:
> Do not have open an LMDB database twice in the same process at the
> same time.
We are not getting away with it as easily this time around.
In December 2019, the FreeBSD port for LMDB [started using robust
mutexes][7], which FreeBSD started supporting in the 11.0 release. This
broke LMDB-related BIND system tests on FreeBSD. I investigated it and
my conclusion was that the problem was likely caused by some low-level
FreeBSD issue that was over my head. I [reported it][8] and it was
ultimately determined to be an [undefined-behavior-type issue][9] with
what the FreeBSD threading library does when a mutex is unmapped from
memory without being destroyed first. This prompted LMDB maintainers to
merge a [fix][10] which causes LMDB to destroy locktable mutexes when
`mdb_env_close()` is called and the process calling that function is the
only remaining user of the LMDB environment. This change has been
already [applied][11] as a patch to the FreeBSD port of LMDB 0.9.24 and
I fully expect it to be a part of the next LMDB release, i.e. version
0.9.26, as it has also been [merged][12] into the LMDB 0.9 release
branch.
The problem is that the aforementioned fix breaks `rndc reconfig` on
*all* platforms we test on because it breaks the kludge we have been
effectively relying on so far. This is what we do (note that all calls
are for the same LMDB environment on disk, even though the pointers used
below - `envA` and `envB` - are different!):
1. `mdb_env_open(envA)`
2. (`rndc reconfig` is invoked)
3. `mdb_env_open(envB)`
4. `mdb_env_close(envA)`
Since all of this happens within a single process, the `mdb_env_close()`
call from step 4 destroys the locktable mutexes (because it correctly
observes that the current process is the only remaining user of the LMDB
environment at hand), which prevents any subsequent `mdb_txn_begin()`
calls from succeeding. Here is an example system test job which
triggers the problem:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/975003
This problem affects all maintained BIND branches.
The only way I can see to work around the problem yet again without
redesigning the whole thing from the ground up is to employ `MDB_NOLOCK`
and use a mutex for controlling concurrent access to the LMDB database
ourselves. What saves us here is that we already [have][13] a mutex
handy and we can just broaden its scope without bumping the API versions
for our libraries in 9.11. I will submit a merge request implementing
this workaround shortly.
Honestly, though, I am afraid that this will just be another bandaid.
Call me an Eastern European grumbler, but I am not happy with the way
LMDB support has been implemented in BIND. We seem to have [chosen][14]
LMDB because it was apparently performing slightly better than SQLite 3.
The thing is, I do not think our use case needs fast *concurrent* access
to the database; we need something that allows us to add, remove, and
query zone configuration *faster than scanning a flat file sequentially*
(which is what pretty much any sane database should be capable of).
LMDB lives up to its promises about speed, but it comes with a set of
caveats that we need to cater for, which complicates our code given how
BIND works. To make things worse, our implementation of LMDB uses
`#ifdef` guards, which means it shares *some* of the code with the
non-LMDB variant (NZF, a text file), but not *all* of it, which makes
the code harder to follow than it has to be.
Here are some ideas for what we can do in the future to improve the
state of things:
- Rework the LMDB implementation in BIND so that it matches the
intended use of that library. This could be achieved by keeping a
global list of reference-counted LMDB environment objects, each of
which would be associated with a specific view name (not view
instance!). This approach should allow `rndc reconfig` to do
without calling `mdb_env_open()` or `mdb_env_close()`. I think such
a change would be too severe to go into 9.16, though.
- Use a different database that will likely be slower than LMDB, but
might be simpler to use.
- Move LMDB support to a module (easier said than done).
- Drop LMDB support altogether :-)
[1]: http://www.lmdb.tech/doc/group__mdb.html
[2]: https://bugs.openldap.org/show_bug.cgi?id=9278#c4
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bcbc7e2b10f85451466a3cc098f15cddd019ae0f/bin/named/server.c#L12796
[4]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bcbc7e2b10f85451466a3cc098f15cddd019ae0f/lib/dns/view.c#L2135
[5]: https://bugs.isc.org/Ticket/Display.html?id=46556#txn-508940
[6]: http://www.lmdb.tech/doc/index.html
[7]: https://svnweb.freebsd.org/ports?view=revision&revision=519246
[8]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493
[9]: https://bugs.openldap.org/show_bug.cgi?id=9278#c3
[10]: https://git.openldap.org/openldap/openldap/-/commit/2fd44e325195ae81664eb5dc36e7d265927c5ebc
[11]: https://svnweb.freebsd.org/ports?view=revision&revision=539380
[12]: https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7d655cf15a60e31249
[13]: https://gitlab.isc.org/isc-projects/bind9/-/blob/d35101e4338c3254113b8f51d178ac44170d412f/lib/dns/include/dns/view.h#L227
[14]: https://bugs.isc.org/Ticket/Display.html?id=39837#txn-430786
[^1]: The docs *do* in fact state the same thing, see below.
August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1975host does not report missing records on default lookups2020-12-15T12:38:43ZPetr Menšíkhost does not report missing records on default lookups<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
host does not report missing records, when no type was gived and name does exist, but no queried records exist.
### BIND version used
```
BIND 9.16.4-RedHat-9.16.4-2.fc32 (Stable Release) <id:0849b42>
running on Linux x86_64 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.1.1 20200507 (Red Hat 10.1.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
host 1.0.0.127.in-addr.arpa
### What is the current *bug* behavior?
Nothing is printed at all. No error, no missing type.
### What is the expected *correct* behavior?
Host should print similar message when type is explicitly given.
1.0.0.127.in-addr.arpa has no A, AAAA nor MX record
### Relevant configuration files
none
### Relevant logs and/or screenshots
```
host 1.0.0.127.in-addr.arpa
host -t mx 1.0.0.127.in-addr.arpa
1.0.0.127.in-addr.arpa has no MX record
```
### Possible fixes
Some counter for summary for one name, when all of them got responses of NOERROR
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/dig/host.c#L568
Reported originally on Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1850685January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1974ThreadSanitizer: data race in dup2020-09-17T07:53:56ZOndřej SurýThreadSanitizer: data race in dup```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 dup <null>
#1 isc_uv_export netmgr/uv-compat.c:162
#2 accept_connection netmgr/tcp.c:882
#3 tcp_connection_cb netmgr/tcp.c:392
...```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 dup <null>
#1 isc_uv_export netmgr/uv-compat.c:162
#2 accept_connection netmgr/tcp.c:882
#3 tcp_connection_cb netmgr/tcp.c:392
#4 uv__server_io <null>
#5 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 epoll_ctl <null>
#1 uv__platform_invalidate_fd <null>
#2 uv_run <null>
#3 <null> <null>
Location is file descriptor 87 created by thread T1 at:
#0 dup <null>
#1 isc_uv_export netmgr/uv-compat.c:162
#2 accept_connection netmgr/tcp.c:882
#3 tcp_connection_cb netmgr/tcp.c:392
#4 uv__server_io <null>
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:215
#3 create_managers bin/named/main.c:903
#4 setup bin/named/main.c:1217
#5 main bin/named/main.c:1517
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:215
#3 create_managers bin/named/main.c:903
#4 setup bin/named/main.c:1217
#5 main bin/named/main.c:1517
SUMMARY: ThreadSanitizer: data race in dup
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1969Silence CPPCHECK warnings2020-12-17T13:20:36ZMark AndrewsSilence CPPCHECK warningsJob [#972939](https://gitlab.isc.org/isc-projects/bind9/-/jobs/972939) failed for e82527727c42f9bb3e3a6c4f5b2dfd7a13a67c4c:
https://isc-projects.isc-pag.es/-/bind9/-/jobs/972939/artifacts/cppcheck_html/index.html
These appear to be fal...Job [#972939](https://gitlab.isc.org/isc-projects/bind9/-/jobs/972939) failed for e82527727c42f9bb3e3a6c4f5b2dfd7a13a67c4c:
https://isc-projects.isc-pag.es/-/bind9/-/jobs/972939/artifacts/cppcheck_html/index.html
These appear to be false positives with the exception of a now redundant NULL check in update.cJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1968Again: BIND | rbtdb.c:2162: INSIST with bind with 9.11.20 (see #1718)2020-07-02T09:33:14ZHolger WirtzAgain: BIND | rbtdb.c:2162: INSIST with bind with 9.11.20 (see #1718)<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Same problem as #1718, but this time after several hours on two of our three slave servers at the same time:
Sudden crash of the named process.
### BIND version used
```
BIND 9.11.20 (Extended Support Version) <id:f3d1d66>
running on Linux x86_64 3.16.0-10-amd64 #1 SMP Debian 3.16.81-1 (2020-01-17)
built by make with '--prefix=/usr' '--mandir=/usr/share/man' '--libdir=/usr/lib/x86_64-linux-gnu' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--enable-ipv6' '--enable-filter-aaaa' '--with-make-clean'
compiled by GCC 4.9.2
compiled with OpenSSL version: OpenSSL 1.0.1t 3 May 2016
linked to OpenSSL version: OpenSSL 1.0.1t 3 May 2016
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with libjson-c version: 0.11.99
linked to libjson-c version: 0.11.99
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.8
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
```
### Steps to reproduce
```
# Created bind as usual:
VERSION=9.11.20
wget -O bind-$(VERSION).tar.gz https://downloads.isc.org/isc/bind9/$(VERSION)/bind-$(VERSION).tar.gz
wget -O bind-$(VERSION).tar.gz.sha512.asc https://downloads.isc.org/isc/bind9/$(VERSION) /bind-$(VERSION).tar.gz.sha512.asc
gpg --verify bind-$(VERSION).tar.gz.sha512.asc bind-$(VERSION).tar.gz
tar -zxf bind-$(VERSION).tar.gz
bind-$(VERSION)
./configure --prefix=/usr \
--mandir=\$${prefix}/share/man \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--infodir=\$${prefix}/share/info \
--sysconfdir=/etc/bind \
--with-python=python3 \
--localstatedir=/ \
--enable-threads \
--enable-largefile \
--with-libtool \
--enable-shared \
--enable-static \
--with-openssl=/usr \
--with-gssapi=/usr \
--with-gnu-ld \
--enable-ipv6 \
--enable-filter-aaaa
make && make install
```
### What is the current *bug* behavior?
After several hours, bind crashes with the following message in general.log:
```
23-Jun-2020 14:25:01.251 general: rbtdb.c:2162: INSIST(((unsigned int)(isc_atomic_xadd(&(&(node)->references)->refs, 0))) == 0 && node->data == ((void *)0)) failed, back trace
23-Jun-2020 14:25:01.251 general: #0 0x43fe6d in ??
23-Jun-2020 14:25:01.251 general: #1 0x7f382e8ffcfa in ??
23-Jun-2020 14:25:01.251 general: #2 0x7f382fbc73ed in ??
23-Jun-2020 14:25:01.251 general: #3 0x7f382fbc776c in ??
23-Jun-2020 14:25:01.251 general: #4 0x7f382e929a17 in ??
23-Jun-2020 14:25:01.251 general: #5 0x7f382daaa064 in ??
23-Jun-2020 14:25:01.251 general: #6 0x7f382d47862d in ??
23-Jun-2020 14:25:01.251 general: exiting (due to assertion failure)
```
The same (at the same time!) happens on the other dns-slave server:
```
23-Jun-2020 14:25:01.594 general: rbtdb.c:2162: INSIST(((unsigned int)(isc_atomic_xadd(&(&(node)->references)->refs, 0))) == 0 && node->data == ((void *)0)) failed, back trace
23-Jun-2020 14:25:01.594 general: #0 0x43fe6d in ??
23-Jun-2020 14:25:01.594 general: #1 0x7f19743eacfa in ??
23-Jun-2020 14:25:01.594 general: #2 0x7f19756b23ed in ??
23-Jun-2020 14:25:01.594 general: #3 0x7f19756b276c in ??
23-Jun-2020 14:25:01.594 general: #4 0x7f1974414a17 in ??
23-Jun-2020 14:25:01.594 general: #5 0x7f1973595064 in ??
23-Jun-2020 14:25:01.594 general: #6 0x7f1972f6362d in ??
23-Jun-2020 14:25:01.594 general: exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
No crash.
### Relevant configuration files
named.conf:
```
include "/etc/bind/named.conf.local"; // only ACLs, logging and statistic channels
include "/etc/bind/named.conf.options"; // look down
include "/etc/bind/bind.keys";
include "/etc/bind/named.conf.namedboot";
include "/etc/bind/tsig.key";
```
named.options:
```
options {
directory "/var/cache/bind";
pid-file "/var/run/named/named.pid";
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { ::1; ********; };
listen-on { 127.0.0.1; *********; };
allow-query { any; };
allow-transfer { ******; };
recursion no;
version "0";
dnssec-enable yes;
dnssec-validation yes;
tcp-clients 1500;
rate-limit {
responses-per-second 50;
};
};
controls {
inet 127.0.0.1 allow { 127.0.0.1; ::1; };
};
```
### Relevant logs and/or screenshots
general.log:
```
23-Jun-2020 14:25:01.251 general: rbtdb.c:2162: INSIST(((unsigned int)(isc_atomic_xadd(&(&(node)->references)->refs, 0))) == 0 && node->data == ((void *)0)) failed, back trace
23-Jun-2020 14:25:01.251 general: #0 0x43fe6d in ??
23-Jun-2020 14:25:01.251 general: #1 0x7f382e8ffcfa in ??
23-Jun-2020 14:25:01.251 general: #2 0x7f382fbc73ed in ??
23-Jun-2020 14:25:01.251 general: #3 0x7f382fbc776c in ??
23-Jun-2020 14:25:01.251 general: #4 0x7f382e929a17 in ??
23-Jun-2020 14:25:01.251 general: #5 0x7f382daaa064 in ??
23-Jun-2020 14:25:01.251 general: #6 0x7f382d47862d in ??
23-Jun-2020 14:25:01.251 general: exiting (due to assertion failure)
```
### Possible fixes
-July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1965bin/named/unix/os.c warning: '%s' directive output may be truncated on OpenIn...2020-06-29T13:40:19ZMichal Nowakbin/named/unix/os.c warning: '%s' directive output may be truncated on OpenIndianaBIND 9.16.4 compilation with GCC 7.5 on OpenIndiana 2020.04 (`illumos-6682e4c38c`) emitted warning in `bin/named/unix/os.c`:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/oi-userland/components/network/bind/build...BIND 9.16.4 compilation with GCC 7.5 on OpenIndiana 2020.04 (`illumos-6682e4c38c`) emitted warning in `bin/named/unix/os.c`:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/oi-userland/components/network/bind/build/amd64/config.h -I/export/home/newman/oi-userland/components/network/bind/build/amd64 -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4 -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/bin/named/unix/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/bin/named/unix/../include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/isccfg/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isccfg/include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/isccc/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isccc/include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/dns/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/dns/include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/isc/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc/unix/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc/pthreads/include -m64 -O3 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c os.c -fPIC -DPIC -o .libs/os.o
os.c: In function 'getuname':
os.c:920:49: warning: '%s' directive output may be truncated writing up to 256 bytes into a region of size between 253 and 1021 [-Wformat-truncation=]
snprintf(unamebuf, sizeof(unamebuf), "%s %s %s %s", uts.sysname,
^~
uts.machine, uts.release, uts.version);
~~~
os.c:920:2: note: 'snprintf' output between 4 and 1028 bytes into a destination of size 1024
snprintf(unamebuf, sizeof(unamebuf), "%s %s %s %s", uts.sysname,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uts.machine, uts.release, uts.version);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
illumos [snprintf(3c)](https://illumos.org/man/3c/snprintf).July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)