ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-03-20T16:27:14Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3166uvreq freed too early from isc_nm_connecttimeout_cb()2022-03-20T16:27:14ZOndřej Surýuvreq freed too early from isc_nm_connecttimeout_cb()The `isc__nm_uvreq_t` is marked as unused too early in the `isc__nm_connecttimeout_cb()`, the `isc__nm_uvreq_put()` needs to be called from the original connection callback.
Under normal circumstances, this is not a problem because the ...The `isc__nm_uvreq_t` is marked as unused too early in the `isc__nm_connecttimeout_cb()`, the `isc__nm_uvreq_put()` needs to be called from the original connection callback.
Under normal circumstances, this is not a problem because the `isc__nm_uvreq_t` is put onto `sock->inactivereqs` and freed when the `isc__nmsocket_t` is destroyed.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3167ah_frees and ah_handles unused2022-02-23T22:52:35ZOndřej Surýah_frees and ah_handles unusedThe `isc__nmsocket_t` has locked array of `isc_nmhandle_t` that's not used for anything. The `isc__nmhandle_get()` adds the `isc_nmhandle_t` to the locked array (and resized if necessary) and removed when `isc_nmhandle_put()` destroys t...The `isc__nmsocket_t` has locked array of `isc_nmhandle_t` that's not used for anything. The `isc__nmhandle_get()` adds the `isc_nmhandle_t` to the locked array (and resized if necessary) and removed when `isc_nmhandle_put()` destroys the handle. That's all it does.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3168Refactor recursion tracking in lib/ns/query.c2022-10-10T07:40:54ZMichał KępieńRefactor recursion tracking in lib/ns/query.cWhile #3147 was fixed with a change that should be safe to backport
(!5870 only touches statistics-related code), a number of problems in
`lib/ns/query.c` were identified while that problem was being
investigated:
1. [x] (!5882) Code d...While #3147 was fixed with a change that should be safe to backport
(!5870 only touches statistics-related code), a number of problems in
`lib/ns/query.c` were identified while that problem was being
investigated:
1. [x] (!5882) Code duplication.
2. [x] (!5883) Logically unrelated bits of code (e.g. prefetch and RPZ)
share common code paths (e.g. `prefetch_done()`) even
though they do not need to.
3. [x] (!5884) Various features able to initiate recursion use common
memory locations (e.g. `client->fetchhandle`,
`client->query.fetch`), which forces them all to
"cooperate" with each other even though they are all
logically separate.
4. [x] (!5885) One of the overloaded variables is
`client->recursionquota`, which causes recursion quota
to be handled inconsistently.
5. [x] (!5886) The `check_recursionquota()` function needs to be
cleaned up.
Unlike #3147, IMHO addressing the above issues is 9.19+ material due to
the amount of changes involved.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/2327bump up lib versions for the release 2.0.22022-02-27T21:57:32ZRazvan Becheriubump up lib versions for the release 2.0.2kea2.0.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3170tiny typo in doc build script??2022-02-24T14:21:58ZVicky Riskvicky@isc.orgtiny typo in doc build script??in line 151 of https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/arm/conf.py in the main branch
it says
`'logging-cattegories.rst',`
since the file itself is spelled correctly, (logging-categories.rst) presumably whatever we a...in line 151 of https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/arm/conf.py in the main branch
it says
`'logging-cattegories.rst',`
since the file itself is spelled correctly, (logging-categories.rst) presumably whatever we are trying to do in this python script is missing the logging categories file. I dk if this is an actual problem, but I saw it and now I can't unsee it, so I am putting it down here.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/kea/-/issues/2328Bump version in configure.ac after 2.1.3 release2022-02-24T13:18:14ZMarcin GodzinaBump version in configure.ac after 2.1.3 releaseBump up Kea version in `configure.ac` to next development version after 2.1.3 releaseBump up Kea version in `configure.ac` to next development version after 2.1.3 releaseMarcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/23292.0.2 release checklist2022-03-03T10:52:24ZWlodzimierz Wencel2.0.2 release checklist---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaRelease...---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [ ] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have been been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [ ] Check if ReadTheDocs can build Kea documentation.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [ ] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates Gitlab issue and MR for release changes
- adds release entries to ChangeLogs
- regenerates BNF grammar
- regenerates documentation
- regenerates messages
- reorders messages in alphabetical order
- regenerates parsers
- updates copyright dates
- pushes the changes to MR
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. For stable releases, change the default version to point to this stable release.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [ ] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [ ] ***(Support)*** Wait for the signing ticket from the release engineer.
- [ ] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [ ] ***(Support)*** Sign the tarballs.
- [ ] ***(Support)*** Upload signature files to repo.isc.org.
- [ ] ***(Support)*** Place tarballs in public location on FTP site.
- [ ] ***(Support)*** Publish links to downloads on ISC website.
- [ ] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [ ] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [ ] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [ ] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [ ] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.0.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2330Refactor CB v6 unit tests2022-03-04T19:16:26ZThomas MarkwalderRefactor CB v6 unit testsRepeat the unit test refactoring done under #2275 for CB V6.
Create generic CB V6 UT test classes, to house common code currently in mysql_cb_dhcp6_unittest.cc.Repeat the unit test refactoring done under #2275 for CB V6.
Create generic CB V6 UT test classes, to house common code currently in mysql_cb_dhcp6_unittest.cc.kea2.1.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3171Alternatively provide locked isc_queue2022-04-04T19:18:53ZOndřej SurýAlternatively provide locked isc_queueThe hazard pointers based Michael-Scott Queue can be problematic in cases where external plugins needs to schedule work onto the netmgr loops.
Provide an alternative `isc_queue` implementation based on mutex + `ISC_LIST`The hazard pointers based Michael-Scott Queue can be problematic in cases where external plugins needs to schedule work onto the netmgr loops.
Provide an alternative `isc_queue` implementation based on mutex + `ISC_LIST`April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3172BIND is not compatible with LibreSSL 3.5.02022-03-03T09:41:45ZArаm SаrgsyаnBIND is not compatible with LibreSSL 3.5.0### Summary
BIND fails to compile with the newly released LibreSSL 3.5.0.
### BIND version used
BIND 9.18.0
### Steps to reproduce
```
./configure
make -j8
```
### What is the current *bug* behavior?
Compilation error in 3 places...### Summary
BIND fails to compile with the newly released LibreSSL 3.5.0.
### BIND version used
BIND 9.18.0
### Steps to reproduce
```
./configure
make -j8
```
### What is the current *bug* behavior?
Compilation error in 3 places:
```
aes.c: In function 'isc_aes128_crypt':
aes.c:35:24: error: storage size of '_context' isn't known
35 | EVP_CIPHER_CTX _context;
| ^~~~~~~~
aes.c:26:43: error: left-hand operand of comma expression has no effect [-Werror=unused-value]
26 | #define EVP_CIPHER_CTX_new() &(_context), EVP_CIPHER_CTX_init(&_context)
| ^
aes.c:41:13: note: in expansion of macro 'EVP_CIPHER_CTX_new'
41 | c = EVP_CIPHER_CTX_new();
| ^~~~~~~~~~~~~~~~~~
aes.c:35:24: error: unused variable '_context' [-Werror=unused-variable]
35 | EVP_CIPHER_CTX _context;
| ^~~~~~~~
aes.c: In function 'isc_aes192_crypt':
aes.c:55:24: error: storage size of '_context' isn't known
55 | EVP_CIPHER_CTX _context;
| ^~~~~~~~
aes.c:26:43: error: left-hand operand of comma expression has no effect [-Werror=unused-value]
26 | #define EVP_CIPHER_CTX_new() &(_context), EVP_CIPHER_CTX_init(&_context)
| ^
aes.c:61:13: note: in expansion of macro 'EVP_CIPHER_CTX_new'
61 | c = EVP_CIPHER_CTX_new();
| ^~~~~~~~~~~~~~~~~~
aes.c:55:24: error: unused variable '_context' [-Werror=unused-variable]
55 | EVP_CIPHER_CTX _context;
| ^~~~~~~~
aes.c: In function 'isc_aes256_crypt':
aes.c:75:24: error: storage size of '_context' isn't known
75 | EVP_CIPHER_CTX _context;
| ^~~~~~~~
aes.c:26:43: error: left-hand operand of comma expression has no effect [-Werror=unused-value]
26 | #define EVP_CIPHER_CTX_new() &(_context), EVP_CIPHER_CTX_init(&_context)
| ^
aes.c:81:13: note: in expansion of macro 'EVP_CIPHER_CTX_new'
81 | c = EVP_CIPHER_CTX_new();
| ^~~~~~~~~~~~~~~~~~
aes.c:75:24: error: unused variable '_context' [-Werror=unused-variable]
75 | EVP_CIPHER_CTX _context;
| ^~~~~~~~
```
```
openssldh_link.c: In function 'progress_cb':
dst_openssl.h:38:33: error: invalid use of incomplete typedef 'BN_GENCB' {aka 'struct bn_gencb_st'}
38 | #define BN_GENCB_get_arg(x) ((x)->arg)
| ^~
openssldh_link.c:329:18: note: in expansion of macro 'BN_GENCB_get_arg'
329 | u.dptr = BN_GENCB_get_arg(cb);
| ^~~~~~~~~~~~~~~~
openssldh_link.c: In function 'openssldh_generate':
openssldh_link.c:364:18: error: storage size of '_cb' isn't known
364 | BN_GENCB _cb;
| ^~~
openssldh_link.c:364:18: error: unused variable '_cb' [-Werror=unused-variable]
```
```
opensslrsa_link.c: In function 'progress_cb':
dst_openssl.h:38:33: error: invalid use of incomplete typedef 'BN_GENCB' {aka 'struct bn_gencb_st'}
38 | #define BN_GENCB_get_arg(x) ((x)->arg)
| ^~
opensslrsa_link.c:352:18: note: in expansion of macro 'BN_GENCB_get_arg'
352 | u.dptr = BN_GENCB_get_arg(cb);
| ^~~~~~~~~~~~~~~~
opensslrsa_link.c: In function 'opensslrsa_generate':
opensslrsa_link.c:387:18: error: storage size of '_cb' isn't known
387 | BN_GENCB _cb;
| ^~~
opensslrsa_link.c:387:18: error: unused variable '_cb' [-Werror=unused-variable]
```
### What is the expected *correct* behavior?
Clean compile.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
MR PendingMarch 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/kea/-/issues/2332pre 2.0.2 release changes2022-03-03T14:27:16ZWlodzimierz Wencelpre 2.0.2 release changeskea2.0.2https://gitlab.isc.org/isc-projects/bind9/-/issues/3173Make the isc__nm_uvreq_t caching unlocked (or mostly so)2022-03-22T11:01:26ZOndřej SurýMake the isc__nm_uvreq_t caching unlocked (or mostly so)April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3174correctly document "zone" in named.conf man page2022-03-03T09:39:53ZEvan Huntcorrectly document "zone" in named.conf man pageWorking on !5860, I noticed that the `zone` statement isn't documented correctly in the `named.conf` man page: it shows all zone options in a single huge block, leaving out `type`. It should instead be separated into different blocks for...Working on !5860, I noticed that the `zone` statement isn't documented correctly in the `named.conf` man page: it shows all zone options in a single huge block, leaving out `type`. It should instead be separated into different blocks for `type primary` and `type secondary` and so on.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3175Issue 45027 in oss-fuzz: bind9:dns_rdata_fromtext_fuzzer: Abrt in isc_lex_get...2022-03-03T09:36:06ZOndřej SurýIssue 45027 in oss-fuzz: bind9:dns_rdata_fromtext_fuzzer: Abrt in isc_lex_gettokenThere's hard insist instead of the soft bailout when parsing the SVCB record...
I think this is probably not a security issue because:
a) `named-checkzone` would catch this (e.g. would crash too)
b) this is rdata from text - e.g. doesn...There's hard insist instead of the soft bailout when parsing the SVCB record...
I think this is probably not a security issue because:
a) `named-checkzone` would catch this (e.g. would crash too)
b) this is rdata from text - e.g. doesn't apply for the data received on the wire.
Nevertheless, making this confidential for now.
I can reproduce this on `v9_16`, `v9_18`, and `main` branches
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 384, 0, 140431660734688, 140431699229637, 2, 9223372036854775822}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007fb8cdf00537 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x26100000200, sa_sigaction = 0x26100000200}, sa_mask = {__val = {140431711078465, 0, 64, 140431656681472, 140431656521728, 140736650060432, 140431710781940, 140736650060496, 140431656656904, 140431656521728, 0, 140736650060544, 140431710827809, 0, 261993005190, 140431656656896}}, sa_flags = -889053184, sa_restorer = 0xffffffffffffffff}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007fb8ce3c40e9 in isc_assertion_failed (file=0x7fb8ce4132d8 "lex.c", line=677, type=isc_assertiontype_insist, cond=0x7fb8ce413539 "remaining > 0U") at assertions.c:50
No locals.
#3 0x00007fb8ce3d3fda in isc_lex_gettoken (lex=0x7fb8cb022000, options=12579, tokenp=0x7fffce08a4a0) at lex.c:677
source = 0x7fb8cb02a000
c = 61
done = false
no_comments = false
escaped = false
state = lexstate_string
saved_state = lexstate_start
buffer = 0x7fffce08a690
stream = 0x7fb8cdf589c6 <__vsnprintf_internal+166>
curr = 0x7fb8cb025100 ""
prev = 0x0
remaining = 0
as_ulong = 8
saved_options = 12579
result = 32767
#4 0x00007fb8ce3d469e in isc_lex_getmastertoken (lex=0x7fb8cb022000, token=0x7fffce08a4a0, expect=isc_tokentype_qvpair, eol=true) at lex.c:931
options = 12579
result = 3456673605
#5 0x00007fb8ce216f18 in generic_fromtext_in_svcb (rdclass=1, type=65, lexer=0x7fb8cb022000, origin=0x7fb8ce381780 <root>, options=0, target=0x7fffce08a700, callbacks=0x0) at rdata/in_1/svcb_64.c:582
_r = 3405926401
token = {type = isc_tokentype_string, value = {as_char = 0 '\000', as_ulong = 140431656636416, as_region = {base = 0x7fb8cb025000 '\377' <repeats 200 times>..., length = 1}, as_textregion = {base = 0x7fb8cb025000 '\377' <repeats 200 times>..., length = 1}, as_pointer = 0x7fb8cb025000}}
name = {magic = 1145983854, ndata = 0x7fffce08a742 "\001\377", length = 3, labels = 2, attributes = 1, offsets = 0x0, buffer = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}
buffer = {magic = 1114990113, base = 0x7fb8cb025000, length = 1, used = 1, current = 1, active = 1, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}
alias = false
ok = true
used = 5
#6 0x00007fb8ce219b78 in fromtext_in_https (rdclass=1, type=65, lexer=0x7fb8cb022000, origin=0x0, options=0, target=0x7fffce08a700, callbacks=0x0) at rdata/in_1/https_65.c:30
No locals.
#7 0x00007fb8ce23073f in dns_rdata_fromtext (rdata=0x7fffce08a6d0, rdclass=1, type=65, lexer=0x7fb8cb022000, origin=0x0, options=0, mctx=0x7fb8cb009000, target=0x7fffce08a700, callbacks=0x0) at rdata.c:1019
result = ISC_R_SUCCESS
region = {base = 0x939366138 <error: Cannot access memory at address 0x939366138>, length = 3405914112}
st = {magic = 1114990113, base = 0x7fffce08a740, length = 65536, used = 0, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}
token = {type = isc_tokentype_string, value = {as_char = 0 '\000', as_ulong = 140431656636416, as_region = {base = 0x7fb8cb025000 '\377' <repeats 200 times>..., length = 1}, as_textregion = {base = 0x7fb8cb025000 '\377' <repeats 200 times>..., length = 1}, as_pointer = 0x7fb8cb025000}}
lexoptions = 291
name = 0x0
line = 254
callback = 0x7fb8ce23c007 <default_fromtext_callback>
tresult = ISC_R_CRYPTOFAILURE
length = 257
unknown = false
#8 0x000055cf401a96df in LLVMFuzzerTestOneInput (data=0x55cf406c0ce0 "1 65 8 \377 ", '\377' <repeats 191 times>..., size=266) at dns_rdata_fromtext.c:139
mctx = 0x7fb8cb009000
lex = 0x7fb8cb022000
token = {type = isc_tokentype_number, value = {as_char = 65 'A', as_ulong = 65, as_region = {base = 0x41 <error: Cannot access memory at address 0x41>, length = 0}, as_textregion = {base = 0x41 <error: Cannot access memory at address 0x41>, length = 0}, as_pointer = 0x41}}
result = ISC_R_SUCCESS
options = 1
rdtype = 65
rdclass = 1
wiredata = "\000\b\001\377\000\377\377\377\000\000\000\000\000\000\000\000!fuB\000\000\000\000\220\247\b\316\377\177\000\000\000\000\001\000C", '\000' <repeats 11 times>, '\377' <repeats 16 times>, '\000' <repeats 16 times>, "\001\001\002\222\000;\243IB\334t\025./,@\215)쥥 \347\362\340k\271D\364ܣF\272\366<\033\027v\025\324f\366ķ\034!jP)+Ռ\236\275\322\367N8\376Q\377ԌC2l\274f\306\067\032\364?\305P<\377\272r\026>\233\354K k\255\063\310e\272,W\275\257\311\372\245\241\353\224nh\216\247\364\005\252\207O\357", '\000' <repeats 57385 times>...
wirebuf = {magic = 1114990113, base = 0x7fffce08a740, length = 65536, used = 5, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}
rdata = {data = 0x0, length = 0, rdclass = 0, type = 0, flags = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
name = 0x0
inbuf = {magic = 1114990113, base = 0x55cf406c0ce0, length = 266, used = 266, current = 266, active = 266, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}
#9 0x000055cf401a98b9 in test_one_file (filename=0x7fffce09a870 "/home/ondrej/Projects/bind9/fuzz/dns_rdata_fromtext.in/clusterfuzz-testcase-minimized-dns_rdata_fromtext_fuzzer-5721681535041536.fuzz") at main.c:53
fd = 4
st = {st_dev = 2431, st_ino = 4201174, st_nlink = 1, st_mode = 33188, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 266, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1645979144, tv_nsec = 431668003}, st_mtim = {tv_sec = 1645979144, tv_nsec = 431668003}, st_ctim = {tv_sec = 1645979144, tv_nsec = 431668003}, __glibc_reserved = {0, 0, 0}}
data = 0x55cf406c0ce0 "1 65 8 \377 ", '\377' <repeats 191 times>...
n = 266
#10 0x000055cf401a9a4c in test_all_from (dirname=0x7fffce09a980 "/home/ondrej/Projects/bind9/fuzz/dns_rdata_fromtext.in") at main.c:89
filename = "/home/ondrej/Projects/bind9/fuzz/dns_rdata_fromtext.in/clusterfuzz-testcase-minimized-dns_rdata_fromtext_fuzzer-5721681535041536.fuzz"
dirp = 0x55cf406b8b20
dp = 0x55cf406b8c20
#11 0x000055cf401a9c0d in main (argc=1, argv=0x7fffce09ba88) at main.c:125
corpusdir = "/home/ondrej/Projects/bind9/fuzz/dns_rdata_fromtext.in\000\000H\252\t\316\377\177\000\000D\252\t\316\377\177\000\000\000 \000\000\000\000\000\000\000 ", '\000' <repeats 14 times>, "\b\003\357\315\270\177\000\000\330$\356\315\270\177\000\000\006\021\203\315\270\177\000\000\033\237ֽ\000\000\000\000|Z\367\002\000\000\000\000D\252\t\316\377\177\000\000(\350\362̸\177\000\000\020\253\t\316\377\177\000\000\230\t\203\315\270\177\000\000\000\253\t\316\377\177\000\000 \000\000\000\000\000\000\000\070~\261\001\000\000\000\000\070~\261\001", '\000' <repeats 12 times>...
target = 0x7fffce09c338 "dns_rdata_fromtext"
```
[clusterfuzz-testcase-minimized-dns_rdata_fromtext_fuzzer-5721681535041536.fuzz](/uploads/d23982560f5152b9e5ef80a8f06e39f2/clusterfuzz-testcase-minimized-dns_rdata_fromtext_fuzzer-5721681535041536.fuzz)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3176Issue 45110 by ClusterFuzz-External: bind9:dns_master_load_fuzzer: Undefined-...2022-03-03T09:29:36ZMark AndrewsIssue 45110 by ClusterFuzz-External: bind9:dns_master_load_fuzzer: Undefined-shift in soa_get(unsigned char *p) is being promoted to (int) before being shifted by 24 when the value in > 127 which is undefined behaviour in C. Cast to (unsigned int) or equivalent.
There are a couple of other instance based on examination of the ...(unsigned char *p) is being promoted to (int) before being shifted by 24 when the value in > 127 which is undefined behaviour in C. Cast to (unsigned int) or equivalent.
There are a couple of other instance based on examination of the code base.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3177"INSIST(0);" assertion failure in isc__nmsocket_reset()2022-02-28T10:20:53ZMichał Kępień"INSIST(0);" assertion failure in isc__nmsocket_reset()The following crash occurred in GitLab CI on FreeBSD:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2326508
<details>
<summary>Click to expand/collapse backtrace</summary>
```
D:rndc:Core was generated by `/builds/isc-projects/bind...The following crash occurred in GitLab CI on FreeBSD:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2326508
<details>
<summary>Click to expand/collapse backtrace</summary>
```
D:rndc:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D rndc-ns6 -X named.lock -m no'.
D:rndc:Program terminated with signal SIGABRT, Aborted.
D:rndc:Sent by thr_kill() from pid 7136 and user 1001.
D:rndc:#0 0x000000080150669a in thr_kill () from /lib/libc.so.7
D:rndc:[Current thread is 1 (LWP 101302)]
D:rndc:#0 0x000000080150669a in thr_kill () from /lib/libc.so.7
D:rndc:#1 0x0000000801504af4 in raise () from /lib/libc.so.7
D:rndc:#2 0x000000080147a719 in abort () from /lib/libc.so.7
D:rndc:#3 0x000000000023c240 in assertion_failed (file=0x8002e9282 "netmgr/netmgr.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:238
D:rndc:#4 0x0000000800318afa in isc_assertion_failed (file=0x18bb6 <error: Cannot access memory at address 0x18bb6>, line=6, type=isc_assertiontype_require, cond=0x8015066ba <thr_self+10> "\017\202\024I") at assertions.c:49
D:rndc:#5 0x00000008003076e0 in isc__nmsocket_reset (sock=0x802dea000) at netmgr/netmgr.c:2862
D:rndc:#6 0x0000000800307616 in isc__nmsocket_writetimeout_cb (timer=<optimized out>) at netmgr/netmgr.c:2039
D:rndc:#7 0x000000080110ade6 in ?? () from /usr/local/lib/libuv.so.1
D:rndc:#8 0x000000080110df87 in uv_run () from /usr/local/lib/libuv.so.1
D:rndc:#9 0x0000000800302cdb in nm_thread (worker0=0x8018ae7a0) at netmgr/netmgr.c:700
D:rndc:#10 0x000000080033d856 in isc__trampoline_run (arg=0x8018e0740) at trampoline.c:187
D:rndc:#11 0x000000080133008c in ?? () from /lib/libthr.so.3
D:rndc:#12 0x0000000000000000 in ?? ()
D:rndc:Backtrace stopped: Cannot access memory at address 0x7fffdfbfc000
```
</details>
Looking at the backtrace, it seems like !5848 is the likely culprit as
there was no `isc__nmsocket_writetimeout_cb()` function before that MR.
The relevant code is:
```c
2852 void
2853 isc__nmsocket_reset(isc_nmsocket_t *sock) {
2854 REQUIRE(VALID_NMSOCK(sock));
2855
2856 switch (sock->type) {
2857 case isc_nm_tcpdnssocket:
2858 case isc_nm_tlsdnssocket:
2859 REQUIRE(sock->parent == NULL);
2860 break;
2861 default:
2862 >>> INSIST(0);
2863 ISC_UNREACHABLE();
2864 break;
2865 }
```
It looks like `isc__nmsocket_writetimeout_cb()` is calling
`isc__nmsocket_reset()` for an unexpected socket type.
Out of abundance of caution, I am opening this as a confidential issue
for now as a crash is involved, but I would be surprised if this turns
out to be exploitable.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/2333Sanity checks for Kea 2.0.2 rc12022-03-03T14:27:03ZjenkinsSanity checks for Kea 2.0.2 rc1```
We are now at step SANITY CHECKS of Kea 2.0.2 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Be...```
We are now at step SANITY CHECKS of Kea 2.0.2 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
None
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/2.0.2-rc1
/data/shared/sweng/kea/releases/premium-2.0.2-rc1
/data/shared/sweng/kea/releases/subscription-2.0.2-rc1
SHA256 (kea-2.0.2.tar.gz) = 8d28213bdc8e2bb870a383b30ac1e53d54e1eba43d2f86e5151b08b66aa6cf32
SHA256 (kea-premium-2.0.2.tar.gz) = 888790e4e63453b1101dd1a4a1ec8b5aa4ebaca7dae326dc2163aa858b766f01
SHA256 (kea-subscription-2.0.2.tar.gz) = f772d1c35f944adc0db9e9bf3c05cb9fc0aa978d0eeeecc5dfb19250cc49daad
2) APK, deb, RPM packages on packages.aws.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-2.0/job/pkg/25/
Release versions are:
APK: 2.0.2-r20220227221539: https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20220227221539.apk
deb: 2.0.2-isc20220227221539: https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.0.2-isc20220227221539
RPM: 2.0.2-isc20220227221539.[os]: https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.0.2-isc20220227221539*
Installation instructions are here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks, chapter 4. Sanity Checks, point 9.
```kea2.0.2https://gitlab.isc.org/isc-projects/bind9/-/issues/3178ThreadSanitizer: data race lib/dns/dispatch.c in dns_dispatch_send2023-01-24T11:13:22ZArаm SаrgsyаnThreadSanitizer: data race lib/dns/dispatch.c in dns_dispatch_sendA ThreadSanitizer report in a CI [job](https://gitlab.isc.org/isc-private/bind9/-/jobs/2327824) in the private repository.
```
==================
WARNING: ThreadSanitizer: data race (pid=29526)
Read of size 8 at 0x7b5000020a10 by thre...A ThreadSanitizer report in a CI [job](https://gitlab.isc.org/isc-private/bind9/-/jobs/2327824) in the private repository.
```
==================
WARNING: ThreadSanitizer: data race (pid=29526)
Read of size 8 at 0x7b5000020a10 by thread T9 (mutexes: write M2079, write M542256371492526000):
#0 dns_dispatch_send /builds/isc-private/bind9/lib/dns/dispatch.c (libdns-9.18.0.so+0x66d0c)
#1 req_send /builds/isc-private/bind9/lib/dns/request.c:352:2 (libdns-9.18.0.so+0x18a044)
#2 req_connected /builds/isc-private/bind9/lib/dns/request.c:1016:3 (libdns-9.18.0.so+0x18a044)
#3 dns_dispatch_connect /builds/isc-private/bind9/lib/dns/dispatch.c:1835:5 (libdns-9.18.0.so+0x6619d)
#4 dns_request_createvia /builds/isc-private/bind9/lib/dns/request.c:772:12 (libdns-9.18.0.so+0x18b7f8)
#5 checkds_send_toaddr /builds/isc-private/bind9/lib/dns/zone.c:21358:11 (libdns-9.18.0.so+0x23db16)
#6 task_run /builds/isc-private/bind9/lib/isc/task.c:821:5 (libisc-9.18.0.so+0x75856)
#7 isc_task_run /builds/isc-private/bind9/lib/isc/task.c:901:10 (libisc-9.18.0.so+0x75856)
#8 isc__nm_async_task /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:846:11 (libisc-9.18.0.so+0x2dfa7)
#9 process_netievent /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c (libisc-9.18.0.so+0x2712f)
#10 process_queue /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:1019:16 (libisc-9.18.0.so+0x20f58)
#11 process_all_queues /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:765:25 (libisc-9.18.0.so+0x20f58)
#12 async_cb /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:794:6 (libisc-9.18.0.so+0x20f58)
#13 uv__async_io /usr/src/libuv-v1.43.0/src/unix/async.c:163:5 (libuv.so.1+0x10e82)
#14 isc__trampoline_run /builds/isc-private/bind9/lib/isc/trampoline.c:187:11 (libisc-9.18.0.so+0x7f0d9)
Previous write of size 8 at 0x7b5000020a10 by thread T2 (mutexes: write M686371576748313440):
#0 isc__nmhandle_attach /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:1711:11 (libisc-9.18.0.so+0x24380)
#1 startrecv /builds/isc-private/bind9/lib/dns/dispatch.c:1705:3 (libdns-9.18.0.so+0x67f91)
#2 tcp_connected /builds/isc-private/bind9/lib/dns/dispatch.c:1730:3 (libdns-9.18.0.so+0x6645b)
#3 isc__nm_async_connectcb /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:2735:2 (libisc-9.18.0.so+0x2c625)
#4 isc__nm_connectcb /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:2710:3 (libisc-9.18.0.so+0x29c19)
#5 tcpdns_connect_cb /builds/isc-private/bind9/lib/isc/netmgr/tcpdns.c:249:2 (libisc-9.18.0.so+0x37af9)
#6 uv__stream_connect /usr/src/libuv-v1.43.0/src/unix/stream.c:1390:5 (libuv.so.1+0x22a9f)
#7 isc__trampoline_run /builds/isc-private/bind9/lib/isc/trampoline.c:187:11 (libisc-9.18.0.so+0x7f0d9)
Location is heap block of size 480 at 0x7b5000020a00 allocated by thread T2:
#0 malloc <null> (named+0x45f71d)
#1 mallocx /builds/isc-private/bind9/lib/isc/./jemalloc_shim.h:35:10 (libisc-9.18.0.so+0x5fd97)
#2 mem_get /builds/isc-private/bind9/lib/isc/mem.c:345:8 (libisc-9.18.0.so+0x5fd97)
#3 isc__mem_get /builds/isc-private/bind9/lib/isc/mem.c:760:8 (libisc-9.18.0.so+0x5fd97)
#4 dispatch_allocate /builds/isc-private/bind9/lib/dns/dispatch.c:1090:9 (libdns-9.18.0.so+0x61d5b)
#5 dns_dispatch_createtcp /builds/isc-private/bind9/lib/dns/dispatch.c:1144:2 (libdns-9.18.0.so+0x61ae6)
#6 tcp_dispatch /builds/isc-private/bind9/lib/dns/request.c:417:11 (libdns-9.18.0.so+0x189acd)
#7 get_dispatch /builds/isc-private/bind9/lib/dns/request.c:458:12 (libdns-9.18.0.so+0x189acd)
#8 dns_request_createvia /builds/isc-private/bind9/lib/dns/request.c:719:11 (libdns-9.18.0.so+0x18b16f)
#9 checkds_send_toaddr /builds/isc-private/bind9/lib/dns/zone.c:21358:11 (libdns-9.18.0.so+0x23db16)
#10 task_run /builds/isc-private/bind9/lib/isc/task.c:821:5 (libisc-9.18.0.so+0x75856)
#11 isc_task_run /builds/isc-private/bind9/lib/isc/task.c:901:10 (libisc-9.18.0.so+0x75856)
#12 isc__nm_async_task /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:846:11 (libisc-9.18.0.so+0x2dfa7)
#13 process_netievent /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c (libisc-9.18.0.so+0x2712f)
#14 process_queue /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:1019:16 (libisc-9.18.0.so+0x20f58)
#15 process_all_queues /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:765:25 (libisc-9.18.0.so+0x20f58)
#16 async_cb /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:794:6 (libisc-9.18.0.so+0x20f58)
#17 uv__async_io /usr/src/libuv-v1.43.0/src/unix/async.c:163:5 (libuv.so.1+0x10e82)
#18 isc__trampoline_run /builds/isc-private/bind9/lib/isc/trampoline.c:187:11 (libisc-9.18.0.so+0x7f0d9)
Mutex M2079 (0x7b7c00015008) created at:
#0 pthread_mutex_init <null> (named+0x46251f)
#1 isc__mutex_init /builds/isc-private/bind9/lib/isc/mutex.c:52:8 (libisc-9.18.0.so+0x64b97)
#2 dns_zone_create /builds/isc-private/bind9/lib/dns/zone.c:1148:2 (libdns-9.18.0.so+0x1f4cca)
#3 dns_zonemgr_createzone /builds/isc-private/bind9/lib/dns/zone.c:18937:11 (libdns-9.18.0.so+0x20afca)
#4 configure_zone /builds/isc-private/bind9/bin/named/server.c:6746:3 (named+0x507551)
#5 configure_view /builds/isc-private/bind9/bin/named/server.c:4149:3 (named+0x4fe365)
#6 load_configuration /builds/isc-private/bind9/bin/named/server.c:9277:3 (named+0x4f8661)
#7 run_server /builds/isc-private/bind9/bin/named/server.c:9990:2 (named+0x4e5f75)
#8 task_run /builds/isc-private/bind9/lib/isc/task.c:821:5 (libisc-9.18.0.so+0x75856)
#9 isc_task_run /builds/isc-private/bind9/lib/isc/task.c:901:10 (libisc-9.18.0.so+0x75856)
#10 isc__nm_async_task /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:846:11 (libisc-9.18.0.so+0x2dfa7)
#11 process_netievent /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c (libisc-9.18.0.so+0x2712f)
#12 process_queue /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:1019:16 (libisc-9.18.0.so+0x20f58)
#13 process_all_queues /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:765:25 (libisc-9.18.0.so+0x20f58)
#14 async_cb /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:794:6 (libisc-9.18.0.so+0x20f58)
#15 uv__async_io /usr/src/libuv-v1.43.0/src/unix/async.c:163:5 (libuv.so.1+0x10e82)
#16 isc__trampoline_run /builds/isc-private/bind9/lib/isc/trampoline.c:187:11 (libisc-9.18.0.so+0x7f0d9)
Mutex M542256371492526000 is already destroyed.
Mutex M686371576748313440 is already destroyed.
Thread T9 'isc-net-0008' (tid=29574, running) created by main thread at:
#0 pthread_create <null> (named+0x460dad)
#1 isc_thread_create /builds/isc-private/bind9/lib/isc/thread.c:81:8 (libisc-9.18.0.so+0x7804a)
#2 isc__netmgr_create /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:331:3 (libisc-9.18.0.so+0x20cb1)
#3 isc_managers_create /builds/isc-private/bind9/lib/isc/managers.c:41:2 (libisc-9.18.0.so+0x5e117)
#4 create_managers /builds/isc-private/bind9/bin/named/main.c:922:11 (named+0x4e1a9c)
#5 setup /builds/isc-private/bind9/bin/named/main.c:1186:11 (named+0x4e1a9c)
#6 main /builds/isc-private/bind9/bin/named/main.c:1454:2 (named+0x4e1a9c)
Thread T2 'isc-net-0001' (tid=29549, running) created by main thread at:
#0 pthread_create <null> (named+0x460dad)
#1 isc_thread_create /builds/isc-private/bind9/lib/isc/thread.c:81:8 (libisc-9.18.0.so+0x7804a)
#2 isc__netmgr_create /builds/isc-private/bind9/lib/isc/netmgr/netmgr.c:331:3 (libisc-9.18.0.so+0x20cb1)
#3 isc_managers_create /builds/isc-private/bind9/lib/isc/managers.c:41:2 (libisc-9.18.0.so+0x5e117)
#4 create_managers /builds/isc-private/bind9/bin/named/main.c:922:11 (named+0x4e1a9c)
#5 setup /builds/isc-private/bind9/bin/named/main.c:1186:11 (named+0x4e1a9c)
#6 main /builds/isc-private/bind9/bin/named/main.c:1454:2 (named+0x4e1a9c)
SUMMARY: ThreadSanitizer: data race /builds/isc-private/bind9/lib/dns/dispatch.c in dns_dispatch_send
==================
ThreadSanitizer: reported 1 warnings
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/3179[question] bind9 docker fail to initiate2022-11-25T17:11:39Zjimmymcheung[question] bind9 docker fail to initiateI tried to run the las test bind (9.18) docker on my server (CPU is arm32v7 architecture) but it cannot initiate, with the following error message displayed in console:
`exec user process caused: exec format error`
I looked up online but...I tried to run the las test bind (9.18) docker on my server (CPU is arm32v7 architecture) but it cannot initiate, with the following error message displayed in console:
`exec user process caused: exec format error`
I looked up online but no where explicate the hardware requirement of running this docker image.
Is there anywhere specified the min system requirement? Thankshttps://gitlab.isc.org/isc-projects/kea/-/issues/2334mysql_cb and pgsql_cb typo in createOptionAuditDHCP62022-03-14T18:58:01ZRazvan Becheriumysql_cb and pgsql_cb typo in createOptionAuditDHCP6```
SELECT dhcp6_pd_pool.subnet_id INTO sid FROM dhcp6_pd_pool WHERE id = pool_id;
UPDATE dhcp6_subnet SET modification_ts = p_modification_ts
WHERE subnet_id = sid;
```
vs
```
SELECT dhcp6_pd_pool.subnet_id I...```
SELECT dhcp6_pd_pool.subnet_id INTO sid FROM dhcp6_pd_pool WHERE id = pool_id;
UPDATE dhcp6_subnet SET modification_ts = p_modification_ts
WHERE subnet_id = sid;
```
vs
```
SELECT dhcp6_pd_pool.subnet_id INTO sid FROM dhcp6_pd_pool WHERE id = pd_pool_id;
UPDATE dhcp6_subnet SET modification_ts = p_modification_ts
WHERE subnet_id = sid;
```
notice ```pool_id``` vs ```pd_pool_id```kea2.1.4