BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-25T13:45:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4649All TSAN-enabled builds fail in AWS-based GitLab CI jobs2024-03-25T13:45:40ZMichał KępieńAll TSAN-enabled builds fail in AWS-based GitLab CI jobs[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSa...[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSanitizer: unexpected memory mapping 0x7d00e0772000-0x7d00e0c00000
While it is not clear what exactly happened, here are two jobs that were
run in CI for the same commit:
- [2024-03-20 14:24, passed][2]
- [2024-03-20 16:41, failed][3]
The refreshed TSAN image was pushed to the container registry at 15:13.
The TSAN builds seemingly still work fine with the refreshed TSAN image
on our bare metal runners, which use older kernels. This is consistent
with similar reports found online:
https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels
The simplest course of action is to apply the workaround mentioned in
the StackOverflow post above (`sysctl vm.mmap_rnd_bits=28`) and remove
it once the issue resolves itself as kernels and packages get updated
over time.
[1]: https://gitlab.isc.org/isc-projects/images/-/pipelines/168133
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4142725
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143237April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4648pytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.py2024-03-21T12:09:20ZMark Andrewspytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.pyJob [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in...Job [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in _call_runtest_hook
INTERNALERROR> reraise = (runner.Exit,)
INTERNALERROR> AttributeError: module '_pytest.runner' has no attribute 'Exit'
INTERNALERROR> Traceback (most recent call last):
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4646CID 488065: Null pointer dereferences (REVERSE_INULL)2024-03-19T22:41:36ZMichal NowakCID 488065: Null pointer dereferences (REVERSE_INULL)Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROT...Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROTTL);
4802 }
4803 atomic_init(&newheader->count,
4804 atomic_fetch_add_relaxed(&init_count, 1));
>>> CID 488065: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4805 if (version != NULL) {
4806 newheader->serial = version->serial;
4807
4808 if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
4809 DNS_SLABHEADER_SETATTR(newheader,
4810 DNS_SLABHEADERATTR_RESIGN);
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4645CID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", ...2024-03-19T22:41:36ZMichal NowakCID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences itCoverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 ...Coverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 changed->dirty = true;
1993 }
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1994 maybe_update_recordsandsize(false, version, header,
1995 nodename->length);
1996 }
1997 } else {
1998 /*
1999 * No non-IGNORED rdatasets of the given type exist at
/lib/dns/qpzone.c: 1972 in add()
1966 if (topheader_prev != NULL) {
1967 topheader_prev->next = newheader;
1968 } else {
1969 node->data = newheader;
1970 }
1971 newheader->next = topheader->next;
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1972 maybe_update_recordsandsize(false, version, header,
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
/lib/dns/qpzone.c: 1979 in add()
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
1978 resigninsert(qpdb, idx, newheader);
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "resigndelete", which dereferences it.
1979 resigndelete(qpdb, version,
1980 header DNS__DB_FLARG_PASS);
1981 }
1982 if (topheader_prev != NULL) {
1983 topheader_prev->next = newheader;
1984 } else {
/lib/dns/qpzone.c: 2061 in add()
2055 newheader->next = node->data;
2056 node->data = newheader;
2057 }
2058 }
2059 }
2060
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
2061 maybe_update_recordsandsize(true, version, newheader, nodename->length);
2062
2063 /*
2064 * Check if the node now contains CNAME and other data.
2065 */
2066 if (version != NULL && cname_and_other(node, version->serial)) {
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4644Make BIND 9.16.48 got warnings and got errors whtn configure with --enable-de...2024-03-18T03:31:51Znanwn147929@alibaba-inc.comMake BIND 9.16.48 got warnings and got errors whtn configure with --enable-developer<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
Compilation got error when configure with developer mode enabled.
### BIND version affected
BIND 9.16.48
### Steps to reproduce
1. Configure by default options `./configure`, and compile source code `make`
2. Configure by enable tests `./configure --with-cmocka --enable-developer`, and compile source code `make; make test`
### What is the current *bug* behavior?
1. Compilation by default configuration
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
gcc -std=gnu99 -include /home/wn147929/bind/bind-9.16.48/config.h -I/home/wn147929/bind/bind-9.16.48 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I. -I/home/wn147929/bind/bind-9.16.48/lib/dns/include -I../../lib/dns/include -DOPENSSL_SUPPRESS_DEPRECATED -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c base64.c
In file included from ./include/isc/assertions.h:21:0,
from ./include/isc/list.h:16,
from ./include/isc/types.h:32,
from ./include/isc/base64.h:20,
from base64.c:18:
base64.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
```
2. Compilation with developer mode enabled
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
cc1: all warnings being treated as errors
```
### What is the expected *correct* behavior?
Compile success
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4642[dig] +ednsflags do not enable EDNS2024-03-17T03:16:43ZStéphane Bortzmeyer[dig] +ednsflags do not enable EDNS### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by mak...### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by make with default
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with liburcu version: 0.13.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
```
dig +noedns +ednsflags=0x4000 isc.org SOA
``
### What is the current *bug* behavior?
EDNS is still disabled
### What is the expected *correct* behavior?
+ednsflags should enable EDNS, like +nsid or +dnssec do. (Or may be only if the value is not-zero.)
/label ~Bughttps://gitlab.isc.org/isc-projects/bind9/-/issues/4641dig +ednsflags does not re-enable EDNS2024-03-17T03:12:44ZMark Andrewsdig +ednsflags does not re-enable EDNS+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the same+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the sameApril 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4640Checkzone in system test leaks queries2024-03-21T02:40:22ZMark AndrewsCheckzone in system test leaks queriesThe checkzone "checking with max ttl (text)" test leaks queries.The checkzone "checking with max ttl (text)" test leaks queries.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4639Add OpenSSL Flags to proxystream_test2024-03-14T23:42:27ZSamuel ChiangAdd OpenSSL Flags to proxystream_testproxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch pr...proxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch provided below :smile:
```
diff --git a/tests/isc/Makefile.am b/tests/isc/Makefile.am
index 5cdd915..6ee1935 100644
--- a/tests/isc/Makefile.am
+++ b/tests/isc/Makefile.am
@@ -115,10 +115,12 @@ proxyheader_test_SOURCES = \
proxyheader_test_data.h
proxystream_test_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(OPENSSL_CFLAGS)
proxystream_test_LDADD = \
- $(LDADD)
+ $(LDADD) \
+ $(OPENSSL_LIBS)
proxystream_test_SOURCES = \
proxystream_test.c \
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4637host, dig and nslookup don't resolve IDN domains when not used in a tty2024-03-16T06:49:38ZDirk Stöckerhost, dig and nslookup don't resolve IDN domains when not used in a tty### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve t...### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve the domain.
See also my initial bug report to perl (https://github.com/Perl/perl5/issues/22080) which points to the exact code location for this bug.
### BIND version affected
I'm using bind-utils-9.18.24-1.1.x86_64 on openSUSE Tumbleweed. Same happens on older version (Ubuntu LTS).
### Steps to reproduce
See description above
1. Call `host stöcker.eu |cat` in Linux shell
### What is the current *bug* behavior?
Does not resolve a correct name
### What is the expected *correct* behavior?
Does resolve the name whether it's a tty or not.
### Relevant configuration files
none
### Relevant logs
noneNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4633Undefined behaviour in rdataslab.c2024-03-21T12:20:05ZMark AndrewsUndefined behaviour in rdataslab.cmemmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.memmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4632Intermittent hang in dns__db_findnode() during RPZ-enabled "stress" test2024-03-28T11:26:58ZMichał KępieńIntermittent hang in dns__db_findnode() during RPZ-enabled "stress" test`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation ...`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation differs):
https://gitlab.isc.org/isc-projects/bind9/-/jobs/4114341
Artifacts were retained for the failed job.
```
2024-03-12:09:46:32 ERROR: Core dump file /builds/isc-private/bind9/output/ns4/core.24295 found
Core was generated by `/builds/isc-private/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
225 if (read_indicator_isempty(rwl)) {
[Current thread is 1 (Thread 0x7ff91fc75600 (LWP 24295))]
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
#1 0x00007ff920ee4355 in isc_rwlock_wrlock (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:246
#2 0x00007ff920cdf797 in findnode (db=0x7ff91f859500, name=0x7ff91edf0400, create=<optimized out>, nodep=0x7fffc0aa4f58) at qpcache.c:2901
#3 0x00007ff920c4e924 in dns__db_findnode (db=<optimized out>, name=name@entry=0x7ff91edf0400, create=create@entry=true, nodep=nodep@entry=0x7fffc0aa4f58) at db.c:439
#4 0x00007ff920d41d31 in cache_name (fctx=fctx@entry=0x7ff8fa5eec00, name=0x7ff91edf0400, message=message@entry=0x7ff8f9f13c80, addrinfo=addrinfo@entry=0x7ff8f9f067f0, now=now@entry=1710232927) at resolver.c:5803
#5 0x00007ff920d4283d in cache_message (fctx=fctx@entry=0x7ff8fa5eec00, message=0x7ff8f9f13c80, addrinfo=0x7ff8f9f067f0, now=1710232927) at resolver.c:6223
#6 0x00007ff920d4caa2 in resquery_response (eresult=<optimized out>, region=0x7fffc0aa5470, arg=0x7ff8fa2c1000) at resolver.c:7625
#7 0x00007ff920c55e6f in udp_recv (handle=0x7ff8f9d30000, eresult=<optimized out>, region=0x7fffc0aa5470, arg=<optimized out>) at dispatch.c:619
#8 0x00007ff920ea6349 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#9 0x00007ff920ea641b in isc__nm_readcb (sock=sock@entry=0x7ff8fa58e500, uvreq=uvreq@entry=0x7ff8fa539200, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#10 0x00007ff920eb7b40 in isc__nm_udp_read_cb (handle=<optimized out>, nrecv=244, buf=0x7fffc0aa5540, addr=0x7fffc0aa5590, flags=0) at netmgr/udp.c:589
#11 0x00007ff9205bb72a in uv__udp_recvmsg (handle=0x7ff8fa58e7c0) at /usr/src/libuv-v1.48.0/src/unix/udp.c:267
#12 0x00007ff9205bb022 in uv__udp_io (loop=0x7ff91f837020, w=0x7ff8fa58e840, revents=1) at /usr/src/libuv-v1.48.0/src/unix/udp.c:142
#13 0x00007ff9205c0e70 in uv__io_poll (loop=0x7ff91f837020, timeout=612) at /usr/src/libuv-v1.48.0/src/unix/linux.c:1528
#14 0x00007ff9205a5fa4 in uv_run (loop=0x7ff91f837020, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.48.0/src/unix/core.c:448
#15 0x00007ff920ecc52d in loop_thread (arg=arg@entry=0x7ff91f837000) at loop.c:284
#16 0x00007ff920edd775 in thread_body (wrap=0x7ff91f8d8380) at thread.c:85
#17 0x00007ff920edd7ef in isc_thread_main (func=func@entry=0x7ff920ecc4a2 <loop_thread>, arg=0x7ff91f837000) at thread.c:116
#18 0x00007ff920ecd204 in isc_loopmgr_run (loopmgr=0x7ff91f80ea80) at loop.c:456
#19 0x0000000000425250 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1574
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4631CID 487884: Dead code in lib/dns/qpcache.c2024-03-14T11:50:20ZMichal NowakCID 487884: Dead code in lib/dns/qpcache.cCoverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->...Coverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->next = newheader;
3457 qpnode->dirty = 1;
3458 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3459 changed->dirty = true;
3460 }
3461 } else {
3462 /*
3463 * No rdatasets of the given type exist at the node.
3464 */
```
```c
/lib/dns/qpcache.c: 3409 in add()
3403 }
3404 newheader->next = topheader->next;
3405 newheader->down = topheader;
3406 topheader->next = newheader;
3407 qpnode->dirty = 1;
3408 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3409 changed->dirty = true;
3410 }
3411 mark_ancient(header);
3412 if (sigheader != NULL) {
3413 mark_ancient(sigheader);
3414 }
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4630CID 487883: Null pointer dereference in lib/dns/qpzone.c2024-03-14T00:31:50ZMichal NowakCID 487883: Null pointer dereference in lib/dns/qpzone.cCoverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferre...Coverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferred until closeversion() is called.
4933 */
4934 if (result == ISC_R_SUCCESS && version == NULL) {
>>> CID 487883: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "version" to "setsecure", which dereferences it.
4935 setsecure(db, version, qpdb->origin);
4936 }
4937
4938 return (result);
4939 }
4940
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4629CID 487882: Error handling issues in lib/dns/qpzone.c2024-03-14T14:12:59ZMichal NowakCID 487882: Error handling issues in lib/dns/qpzone.cCoverity Scan claims we should consider checking the return value of `dns_qpiter_next()` in `lib/dns/qpzone.c` as done elsewhere:
```c
/lib/dns/qpzone.c: 2804 in activeempty()
2798 * of the name we were searching for. Step the iter...Coverity Scan claims we should consider checking the return value of `dns_qpiter_next()` in `lib/dns/qpzone.c` as done elsewhere:
```c
/lib/dns/qpzone.c: 2804 in activeempty()
2798 * of the name we were searching for. Step the iterator
2799 * forward, then step() will continue forward until it
2800 * finds a node with active data. If that node is a
2801 * subdomain of the one we were looking for, then we're
2802 * at an active empty nonterminal node.
2803 */
>>> CID 487882: Error handling issues (CHECKED_RETURN)
>>> Calling "dns_qpiter_next" without checking return value (as is done elsewhere 26 out of 27 times).
2804 dns_qpiter_next(it, NULL, NULL, NULL);
2805 return (step(search, it, FORWARD, next) &&
2806 dns_name_issubdomain(next, current));
2807 }
2808
2809 static bool
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4628CID 487827: Control flow issues (DEADCODE) in lib/dns/qp-zonedb.c2024-03-11T18:39:47ZMichal NowakCID 487827: Control flow issues (DEADCODE) in lib/dns/qp-zonedb.cCoverity Scan claims dead code in `lib/dns/qp-zonedb.c` (#4411).
```
/lib/dns/qp-zonedb.c: 1600 in loadnode()
1594 * just now getting an NSEC record.
1595 */
1596 if (node->nsec == DNS_DB_NSEC_HAS_NSEC) {
1597 ...Coverity Scan claims dead code in `lib/dns/qp-zonedb.c` (#4411).
```
/lib/dns/qp-zonedb.c: 1600 in loadnode()
1594 * just now getting an NSEC record.
1595 */
1596 if (node->nsec == DNS_DB_NSEC_HAS_NSEC) {
1597 goto done;
1598 }
1599 } else {
>>> CID 487827: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "goto done;".
1600 goto done;
1601 }
1602
1603 if (!hasnsec) {
1604 goto done;
1605 }
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4625Broken trust chain on corner case secure chain2024-03-12T10:11:00ZMatthijs Mekkingmatthijs@isc.orgBroken trust chain on corner case secure chain### Summary
Consider the following chain:
```
parent. DS 1
parent. DS 2
parent. DS 3
parent. RRSIG(DS)
example.parent. DNSKEY 257 id=1
example.parent. DNSKEY 257 id=2
example.parent. DNSKEY 256 id=99
example.parent. RRSIG(DNSKEY) id=1...### Summary
Consider the following chain:
```
parent. DS 1
parent. DS 2
parent. DS 3
parent. RRSIG(DS)
example.parent. DNSKEY 257 id=1
example.parent. DNSKEY 257 id=2
example.parent. DNSKEY 256 id=99
example.parent. RRSIG(DNSKEY) id=1
```
This delegation will result in a broken trust chain, despite there is a secure chain via DNSKEY with id=1. There are also broken chains (DS 3 has no corresponding DNSKEY, DNSKEY with id=2 is not signing).
This works in 9.19.20, but no longer in 9.19.21. Could it be the KeyTrap fix in 9.21 that is causing this?
Older versions (9.18, 9.16) are not affected.
### BIND version affected
9.19.21
### Steps to reproduce
To do.
### What is the current *bug* behavior?
Broken trust chain.
### What is the expected *correct* behavior?
Secure answer.
### Relevant configuration files
Default empty config.
### Relevant logs
To do.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4624Invalid durations in configuration files do not cause a syntax error2024-03-14T12:54:59ZMatthijs Mekkingmatthijs@isc.orgInvalid durations in configuration files do not cause a syntax errorFor example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.For example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4623dns_db_setloop at wrong place in cache_create_db2024-03-08T11:48:33ZMark Andrewsdns_db_setloop at wrong place in cache_create_dbdns_db_setloop should only be called if the database creation succeeds.dns_db_setloop should only be called if the database creation succeeds.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4622BIND hangs in qp_makekey2024-03-25T10:53:39ZMichal NowakBIND hangs in qp_makekeyMy home resolver (`main` - 88a5befa2578bf9969652798ff0b3ede2d19e5c8) with QP got stuck after less than an hour of runtime:
```
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11efb74c00 86.49.239.93#37346 (fedoraproject.org): que...My home resolver (`main` - 88a5befa2578bf9969652798ff0b3ede2d19e5c8) with QP got stuck after less than an hour of runtime:
```
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11efb74c00 86.49.239.93#37346 (fedoraproject.org): query: fedoraproject.org IN AAAA +E(0)T (23.88.124.106)
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11d913fc00 86.49.239.93#37388 (fedoraproject.org): query: fedoraproject.org IN AAAA +E(0)T (23.88.124.106)
Mar 06 17:53:18 dns.mnowak.cz named[81103]: client @0x7f11d905c400 86.49.239.93#37265 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:18 dns.mnowak.cz named[81103]: client @0x7f11ef80dc00 86.49.239.93#37366 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:20 dns.mnowak.cz named[81103]: client @0x7f11c5f93400 86.49.239.93#37217 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:20 dns.mnowak.cz named[81103]: client @0x7f11c5e70800 86.49.239.93#37210 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:21 dns.mnowak.cz named[81103]: client @0x7f11d913fc00 86.49.239.93#37346 (download.copr.fedorainfracloud.org): query: download.copr.fedorainfracloud.org IN A +E(0)T (23.88.124.106)
Mar 06 17:53:24 dns.mnowak.cz named[81103]: client @0x7f11c5f80c00 86.49.239.93#37347 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:24 dns.mnowak.cz named[81103]: client @0x7f11c5e6f000 86.49.239.93#37298 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:26 dns.mnowak.cz named[81103]: client @0x7f11c6408800 86.49.239.93#37257 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:31 dns.mnowak.cz named[81103]: client @0x7f11c5e57400 2a02:8308:a006:2b00::901f#56962 (download.copr.fedorainfracloud.org): query: download.copr.fedorainfracloud.org IN A +E(0)T (2a01:4f8:1c17:cdb0::1)
```
I `abort`ed the server to get a core file. Here's a backtrace:
```
#0 dns_qpkey_fromname (key=0x7ffdf559a200 "\002\"%\032\002\034&\026\002 \024''\030% \"&'\002\002", name=0x7f11c6260110) at qp.c:234
#1 0x00007f11f18dd88f in qp_makekey (key=<optimized out>, uctx=<optimized out>, pval=<optimized out>, ival=<optimized out>) at qpdb.c:201
#2 0x00007f11f18bf605 in leaf_qpkey (qpr=..., n=0x7f11f02ee048, key=0x7ffdf559a200 "\002\"%\032\002\034&\026\002 \024''\030% \"&'\002\002") at /home/newman/bind9/lib/dns/qp_p.h:883
#3 fix_iterator (qp=qp@entry=0x7f11f02d82c0, iter=iter@entry=0x7ffdf559c160, start=<optimized out>,
search=search@entry=0x7ffdf559bec0 "\002\"%\032\002\031\030\027\"%\024\034!\031%\024\026\037\"(\027\002\026\"#%\002\027\"*!\037\"\024\027\002\002", searchlen=searchlen@entry=36, bit=bit@entry=37 '%',
offset=9) at qp.c:2152
#4 0x00007f11f18bfeee in dns_qp_lookup (qpr=..., name=name@entry=0x7f11d9108380, foundname=foundname@entry=0x0, iter=iter@entry=0x7ffdf559c160, chain=0x7ffdf559b4a0, chain@entry=0x0,
pval_r=pval_r@entry=0x7ffdf559d178, ival_r=0x0) at qp.c:2284
#5 0x00007f11f18d62c0 in find_coveringnsec (search=search@entry=0x7ffdf559d6b0, name=name@entry=0x7f11d9108380, nodep=nodep@entry=0x7ffdf55a0080, now=now@entry=1709744001,
foundname=foundname@entry=0x7f11d9108100, rdataset=rdataset@entry=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at qp-cachedb.c:636
#6 0x00007f11f18d69ee in cache_find (db=<optimized out>, name=0x7f11d9108380, version=<optimized out>, type=1, options=16, now=<optimized out>, nodep=0x7ffdf55a0080, foundname=0x7f11d9108100,
rdataset=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at qp-cachedb.c:803
#7 0x00007f11f18538f7 in dns__db_findext (db=0x7f11f0259800, name=name@entry=0x7f11d9108380, version=0x0, type=1, options=options@entry=16, now=1709744001, nodep=0x7ffdf55a0080, foundname=0x7f11d9108100,
methods=0x7ffdf559f6f0, clientinfo=0x7ffdf559f660, rdataset=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at db.c:535
#8 0x00007f11f1add5b1 in query_lookup (qctx=qctx@entry=0x7ffdf559fbe0) at query.c:5969
#9 0x00007f11f1ade2f7 in ns__query_start (qctx=qctx@entry=0x7ffdf559fbe0) at query.c:5817
#10 0x00007f11f1ae3b6e in query_setup (client=client@entry=0x7f11d913fc00, qtype=qtype@entry=1) at query.c:5529
#11 0x00007f11f1ae4667 in ns_query_start (client=client@entry=0x7f11d913fc00, handle=handle@entry=0x7f11d9180700) at query.c:12107
#12 0x00007f11f1ac66fe in ns_client_request (handle=0x7f11d9180700, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2231
#13 0x00007f11f1b2a968 in streamdns_on_complete_dnsmessage (dnsasm=<optimized out>, region=0x7ffdf55a0850, sock=0x7f11d9161300, transphandle=0x7f11ee98d500) at netmgr/streamdns.c:147
#14 streamdns_on_dnsmessage_data_cb (dnsasm=<optimized out>, result=<optimized out>, region=0x7ffdf55a0850, cbarg=0x7f11d9161300, userarg=0x7f11ee98d500) at netmgr/streamdns.c:206
#15 0x00007f11f1b2a1c8 in isc__dnsstream_assembler_callcb (dnsasm=0x7f11efb71300, result=ISC_R_SUCCESS, region=0x7ffdf55a0850, userarg=0x0) at ./include/isc/dnsstream.h:306
#16 isc__dnsstream_assembler_handle_message (dnsasm=dnsasm@entry=0x7f11efb71300, userarg=userarg@entry=0x7f11ee98d500) at ./include/isc/dnsstream.h:353
#17 0x00007f11f1b2ab7b in isc__dnsstream_assembler_processing (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500) at ./include/isc/dnsstream.h:370
#18 isc__dnsstream_assembler_incoming_direct (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500, buf=0x7ffdf55a0970, buf_size=65) at ./include/isc/dnsstream.h:396
#19 isc_dnsstream_assembler_incoming (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500, buf=0x7ffdf55a0970, buf_size=65) at ./include/isc/dnsstream.h:508
#20 streamdns_handle_incoming_data (sock=sock@entry=0x7f11d9161300, transphandle=transphandle@entry=0x7f11ee98d500, data=0x7ffdf55a0970, len=65) at netmgr/streamdns.c:242
#21 0x00007f11f1b2ad34 in streamdns_readcb (handle=0x7f11ee98d500, result=ISC_R_SUCCESS, region=0x7ffdf55a0960, cbarg=0x7f11d9161300) at netmgr/streamdns.c:557
#22 0x00007f11f1b30b73 in tls_do_bio (sock=sock@entry=0x7f11d9162200, received_data=received_data@entry=0x7ffdf55b09f0, send_data=send_data@entry=0x0, finish=finish@entry=false) at netmgr/tlsstream.c:679
#23 0x00007f11f1b30fb5 in tls_readcb (handle=0x7f11ee987400, result=ISC_R_SUCCESS, region=0x7ffdf55b09f0, cbarg=0x7f11d9162200) at netmgr/tlsstream.c:840
#24 0x00007f11f1b2314c in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#25 0x00007f11f1b2321e in isc__nm_readcb (sock=sock@entry=0x7f11d9163b00, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#26 0x00007f11f1b2ee80 in isc__nm_tcp_read_cb (stream=<optimized out>, nread=174, buf=0x7ffdf55b0a90) at netmgr/tcp.c:772
#27 0x00007f11f131c6fb in uv.read () from /lib64/libuv.so.1
#28 0x00007f11f131ca78 in uv.stream_io () from /lib64/libuv.so.1
#29 0x00007f11f132262b in uv.io_poll () from /lib64/libuv.so.1
#30 0x00007f11f1309708 in uv_run () from /lib64/libuv.so.1
#31 0x00007f11f1b48255 in loop_thread (arg=arg@entry=0x7f11f0227000) at loop.c:284
#32 0x00007f11f1b5a02e in thread_body (wrap=0x7f11f0325480) at thread.c:85
#33 0x00007f11f1b5a0a7 in isc_thread_main (func=func@entry=0x7f11f1b481ca <loop_thread>, arg=0x7f11f0227000) at thread.c:116
#34 0x00007f11f1b491ea in isc_loopmgr_run (loopmgr=0x7f11f0209a80) at loop.c:456
#35 0x0000000000426ac0 in main (argc=4, argv=0x7ffdf55b4e08) at main.c:1574
```
[bt-full.txt](/uploads/e4d8eb5744a3ea1c45f09cc9bd521294/bt-full.txt)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org