import bind-9.11.26-6.el8

SOURCES/bind-9.11-CVE-2021-25214.patch

@@ -0,0 +1,44 @@
+From 4eff09c6b1e524b0efc393ee948b5c4cdf16ccb8 Mon Sep 17 00:00:00 2001
+From: Mark Andrews <marka@isc.org>
+Date: Wed, 3 Feb 2021 11:10:20 +1100
+Subject: [PATCH] Check SOA owner names in zone transfers
+
+An IXFR containing SOA records with owner names different than the
+transferred zone's origin can result in named serving a version of that
+zone without an SOA record at the apex.  This causes a RUNTIME_CHECK
+assertion failure the next time such a zone is refreshed.  Fix by
+immediately rejecting a zone transfer (either an incremental or
+non-incremental one) upon detecting an SOA record not placed at the apex
+of the transferred zone.
+---
+ lib/dns/xfrin.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/lib/dns/xfrin.c b/lib/dns/xfrin.c
+index 3a3f407289..0ba82e4974 100644
+--- a/lib/dns/xfrin.c
++++ b/lib/dns/xfrin.c
+@@ -477,6 +477,20 @@ xfr_rr(dns_xfrin_ctx_t *xfr, dns_name_t *name, uint32_t ttl,
+ 	    dns_rdatatype_ismeta(rdata->type))
+ 		FAIL(DNS_R_FORMERR);
+ 
++	/*
++	 * Immediately reject the entire transfer if the RR that is currently
++	 * being processed is an SOA record that is not placed at the zone
++	 * apex.
++	 */
++	if (rdata->type == dns_rdatatype_soa &&
++	    !dns_name_equal(&xfr->name, name)) {
++		char namebuf[DNS_NAME_FORMATSIZE];
++		dns_name_format(name, namebuf, sizeof(namebuf));
++		xfrin_log(xfr, ISC_LOG_DEBUG(3), "SOA name mismatch: '%s'",
++			  namebuf);
++		FAIL(DNS_R_NOTZONETOP);
++	}
++
+  redo:
+ 	switch (xfr->state) {
+ 	case XFRST_SOAQUERY:
+-- 
+2.26.3
+

SOURCES/bind-9.11-rh1935152.patch

@@ -0,0 +1,38 @@
+From 4757898440d52b0adbf7ec7ee7f0f89b61aac0fb Mon Sep 17 00:00:00 2001
+From: Mark Andrews <marka@isc.org>
+Date: Fri, 18 Dec 2020 13:31:07 +1100
+Subject: [PATCH] Inactive incorrectly incremented
+
+It is possible to have two threads destroying an rbtdb at the same
+time when detachnode() executes and removes the last reference to
+a node between exiting being set to true for the node and testing
+if the references are zero in maybe_free_rbtdb().  Move NODE_UNLOCK()
+to after checking if references is zero to prevent detachnode()
+changing the reference count too early.
+
+(cherry picked from commit 859d2fdad6d1c6ff20083a4c463a929cbeb26438)
+(cherry picked from commit 25150c15e7cfa73289f04470e2e699ebb7c28fef)
+---
+ lib/dns/rbtdb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
+index 8ea4d47..77ef7a4 100644
+--- a/lib/dns/rbtdb.c
++++ b/lib/dns/rbtdb.c
+@@ -1460,11 +1460,11 @@ maybe_free_rbtdb(dns_rbtdb_t *rbtdb) {
+ 	for (i = 0; i < rbtdb->node_lock_count; i++) {
+ 		NODE_LOCK(&rbtdb->node_locks[i].lock, isc_rwlocktype_write);
+ 		rbtdb->node_locks[i].exiting = true;
+-		NODE_UNLOCK(&rbtdb->node_locks[i].lock, isc_rwlocktype_write);
+ 		if (isc_refcount_current(&rbtdb->node_locks[i].references)
+ 		    == 0) {
+ 			inactive++;
+ 		}
++		NODE_UNLOCK(&rbtdb->node_locks[i].lock, isc_rwlocktype_write);
+ 	}
+ 
+ 	if (inactive != 0) {
+-- 
+2.26.3
+

SOURCES/bind-9.11-rh1980757.patch

@@ -0,0 +1,32 @@
+From a503519533eb375a5ce1f7566bfc153aac980d87 Mon Sep 17 00:00:00 2001
+From: Petr Mensik <pemensik@redhat.com>
+Date: Fri, 9 Jul 2021 20:52:21 +0200
+Subject: [PATCH] Use proper entropy to initialize tsig keyname
+
+Random names used on GSS backed nsupdate can conflict in specific
+situations. That might include starting a lot of machines from
+containers, where they took all similar time to start. PID and timestamp
+would be similar and therefore randomness is quite low. Use entropy to
+generate more random identifier and reduce chance of conflict.
+---
+ bin/nsupdate/nsupdate.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/bin/nsupdate/nsupdate.c b/bin/nsupdate/nsupdate.c
+index 458aa76..d9e5a2b 100644
+--- a/bin/nsupdate/nsupdate.c
++++ b/bin/nsupdate/nsupdate.c
+@@ -2941,7 +2941,9 @@ start_gssrequest(dns_name_t *master) {
+ 
+ 	keyname = dns_fixedname_initname(&fkname);
+ 
+-	isc_random_get(&val);
++	result = isc_entropy_getdata(entropy, &val, sizeof(val), NULL, 0);
++	if (result != ISC_R_SUCCESS)
++		isc_random_get(&val);
+ 	result = isc_string_printf(mykeystr, sizeof(mykeystr), "%u.sig-%s",
+ 				   val, namestr);
+ 	if (result != ISC_R_SUCCESS)
+-- 
+2.31.1
+

SPECS/bind.spec

@@ -68,7 +68,7 @@ Summary:  The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) serv
 Name:     bind
 License:  MPLv2.0
 Version:  9.11.26
-Release:  4%{?PATCHVER:.%{PATCHVER}}%{?PREVER:.%{PREVER}}%{?dist}
+Release:  6%{?PATCHVER:.%{PATCHVER}}%{?PREVER:.%{PREVER}}%{?dist}
 Epoch:    32
 Url:      https://www.isc.org/downloads/bind/
 #
@@ -156,6 +156,12 @@ Patch177:bind-9.11-serve-stale.patch
 Patch178:bind-9.11-dhcp-time-monotonic.patch
 Patch179:bind-9.11-CVE-2020-8625.patch
 Patch180:bind-9.11-CVE-2021-25215.patch
+# https://gitlab.isc.org/isc-projects/bind9/commit/dfadbc9d7b485b1af62d77ad6c309792bbaabfdf
+Patch181:bind-9.11-CVE-2021-25214.patch
+# https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4533/diffs?commit_id=25150c15e7cfa73289f04470e2e699ebb7c28fef
+Patch182:bind-9.11-rh1935152.patch
+# https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5253
+Patch183:bind-9.11-rh1980757.patch
 
 # SDB patches
 Patch11: bind-9.3.2b2-sdbsrc.patch
@@ -552,6 +558,9 @@ are used for building ISC DHCP.
 %patch178 -p1 -b .time-monotonic
 %patch179 -p1 -b .CVE-2020-8625
 %patch180 -p1 -b .CVE-2021-25215
+%patch181 -p1 -b .CVE-2021-25214
+%patch182 -p1 -b .rh1935152
+%patch183 -p1 -b .rh1980757
 
 mkdir lib/dns/tests/testdata/dstrandom
 cp -a %{SOURCE50} lib/dns/tests/testdata/dstrandom/random.data
@@ -1603,8 +1612,16 @@ rm -rf ${RPM_BUILD_ROOT}
 %endif
 
 %changelog
+* Fri Jul 09 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.26-6
+- Use random entropy to generate unique TKEY identifiers (#1980916)
+
+* Fri May 07 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.26-5
+- Fix possible assertion failure isc_refcount_current == 0 in free_rbtdb
+  (#1953056)
+
 * Tue Apr 27 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.26-4
 - Possible assertion failure on DNAME processing (CVE-2021-25215)
+- Insufficient IXFR checks could lead to assertion failure (CVE-2021-25214)
 
 * Mon Feb 15 2021 Petr Menšík <pemensik@redhat.com> - 32:9.11.26-3
 - Fix off-by-one bug in ISC SPNEGO implementation (CVE-2020-8625)