From 0481ee78bbe54f216197f9748e8e3d8cb39c24b5 Mon Sep 17 00:00:00 2001 From: CentOS Sources Date: Mon, 3 Oct 2022 10:55:44 -0400 Subject: [PATCH] import bind-9.16.23-1.el9_0.1 --- SOURCES/bind-9.16-CVE-2022-3080.patch | 116 +++++++++++++++++++++++++ SOURCES/bind-9.16-CVE-2022-38177.patch | 27 ++++++ SOURCES/bind-9.16-CVE-2022-38178.patch | 32 +++++++ SPECS/bind.spec | 13 ++- 4 files changed, 187 insertions(+), 1 deletion(-) create mode 100644 SOURCES/bind-9.16-CVE-2022-3080.patch create mode 100644 SOURCES/bind-9.16-CVE-2022-38177.patch create mode 100644 SOURCES/bind-9.16-CVE-2022-38178.patch diff --git a/SOURCES/bind-9.16-CVE-2022-3080.patch b/SOURCES/bind-9.16-CVE-2022-3080.patch new file mode 100644 index 0000000..998ddf4 --- /dev/null +++ b/SOURCES/bind-9.16-CVE-2022-3080.patch @@ -0,0 +1,116 @@ +From 3bcd32572504ac9b92e3c6ec1e2cee3df3b68309 Mon Sep 17 00:00:00 2001 +From: Petr Mensik +Date: Tue, 20 Sep 2022 11:34:42 +0200 +Subject: [PATCH 2/4] Fix CVE-2022-3080 + +5960. [security] Fix serve-stale crash that could happen when + stale-answer-client-timeout was set to 0 and there was + a stale CNAME in the cache for an incoming query. + (CVE-2022-3080) [GL #3517] +--- + lib/ns/include/ns/query.h | 1 + + lib/ns/query.c | 42 ++++++++++++++++++++++++--------------- + 2 files changed, 27 insertions(+), 16 deletions(-) + +diff --git a/lib/ns/include/ns/query.h b/lib/ns/include/ns/query.h +index 4d48cf6..34b3070 100644 +--- a/lib/ns/include/ns/query.h ++++ b/lib/ns/include/ns/query.h +@@ -145,6 +145,7 @@ struct query_ctx { + bool authoritative; /* authoritative query? */ + bool want_restart; /* CNAME chain or other + * restart needed */ ++ bool refresh_rrset; /* stale RRset refresh needed */ + bool need_wildcardproof; /* wildcard proof needed */ + bool nxrewrite; /* negative answer from RPZ */ + bool findcoveringnsec; /* lookup covering NSEC */ +diff --git a/lib/ns/query.c b/lib/ns/query.c +index 249321c..a450cb7 100644 +--- a/lib/ns/query.c ++++ b/lib/ns/query.c +@@ -5686,7 +5686,6 @@ query_lookup(query_ctx_t *qctx) { + bool dbfind_stale = false; + bool stale_timeout = false; + bool stale_found = false; +- bool refresh_rrset = false; + bool stale_refresh_window = false; + + CCTRACE(ISC_LOG_DEBUG(3), "query_lookup"); +@@ -5868,8 +5867,7 @@ query_lookup(query_ctx_t *qctx) { + "%s stale answer used, an attempt to " + "refresh the RRset will still be made", + namebuf); +- refresh_rrset = STALE(qctx->rdataset); +- qctx->client->nodetach = refresh_rrset; ++ qctx->refresh_rrset = STALE(qctx->rdataset); + } + } else { + /* +@@ -5907,17 +5905,6 @@ query_lookup(query_ctx_t *qctx) { + + result = query_gotanswer(qctx, result); + +- if (refresh_rrset) { +- /* +- * If we reached this point then it means that we have found a +- * stale RRset entry in cache and BIND is configured to allow +- * queries to be answered with stale data if no active RRset +- * is available, i.e. "stale-anwer-client-timeout 0". But, we +- * still need to refresh the RRset. +- */ +- query_refresh_rrset(qctx); +- } +- + cleanup: + return (result); + } +@@ -7737,11 +7724,14 @@ query_addanswer(query_ctx_t *qctx) { + + /* + * On normal lookups, clear any rdatasets that were added on a +- * lookup due to stale-answer-client-timeout. ++ * lookup due to stale-answer-client-timeout. Do not clear if we ++ * are going to refresh the RRset, because the stale contents are ++ * prioritized. + */ + if (QUERY_STALEOK(&qctx->client->query) && +- !QUERY_STALETIMEOUT(&qctx->client->query)) ++ !QUERY_STALETIMEOUT(&qctx->client->query) && !qctx->refresh_rrset) + { ++ CCTRACE(ISC_LOG_DEBUG(3), "query_clear_stale"); + query_clear_stale(qctx->client); + /* + * We can clear the attribute to prevent redundant clearing +@@ -11457,9 +11447,29 @@ ns_query_done(query_ctx_t *qctx) { + /* + * Client may have been detached after query_send(), so + * we test and store the flag state here, for safety. ++ * If we are refreshing the RRSet, we must not detach from the client ++ * in the query_send(), so we need to override the flag. + */ ++ if (qctx->refresh_rrset) { ++ qctx->client->nodetach = true; ++ } + nodetach = qctx->client->nodetach; + query_send(qctx->client); ++ ++ if (qctx->refresh_rrset) { ++ /* ++ * If we reached this point then it means that we have found a ++ * stale RRset entry in cache and BIND is configured to allow ++ * queries to be answered with stale data if no active RRset ++ * is available, i.e. "stale-anwer-client-timeout 0". But, we ++ * still need to refresh the RRset. To prevent adding duplicate ++ * RRsets, clear the RRsets from the message before doing the ++ * refresh. ++ */ ++ message_clearrdataset(qctx->client->message, 0); ++ query_refresh_rrset(qctx); ++ } ++ + if (!nodetach) { + qctx->detach_client = true; + } +-- +2.37.3 + diff --git a/SOURCES/bind-9.16-CVE-2022-38177.patch b/SOURCES/bind-9.16-CVE-2022-38177.patch new file mode 100644 index 0000000..e510079 --- /dev/null +++ b/SOURCES/bind-9.16-CVE-2022-38177.patch @@ -0,0 +1,27 @@ +From df8222fb189708199a185f73543b6e0602c1c72f Mon Sep 17 00:00:00 2001 +From: Petr Mensik +Date: Tue, 20 Sep 2022 11:21:45 +0200 +Subject: [PATCH 3/4] Fix CVE-2022-38177 + +5961. [security] Fix memory leak in ECDSA verify processing. + (CVE-2022-38177) [GL #3487] +--- + lib/dns/opensslecdsa_link.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/lib/dns/opensslecdsa_link.c b/lib/dns/opensslecdsa_link.c +index ce4c8c4..3847896 100644 +--- a/lib/dns/opensslecdsa_link.c ++++ b/lib/dns/opensslecdsa_link.c +@@ -228,7 +228,7 @@ opensslecdsa_verify(dst_context_t *dctx, const isc_region_t *sig) { + } + + if (sig->length != siglen) { +- return (DST_R_VERIFYFAILURE); ++ DST_RET(DST_R_VERIFYFAILURE); + } + + if (!EVP_DigestFinal_ex(evp_md_ctx, digest, &dgstlen)) { +-- +2.37.3 + diff --git a/SOURCES/bind-9.16-CVE-2022-38178.patch b/SOURCES/bind-9.16-CVE-2022-38178.patch new file mode 100644 index 0000000..fecd526 --- /dev/null +++ b/SOURCES/bind-9.16-CVE-2022-38178.patch @@ -0,0 +1,32 @@ +From 132ef295b8407f91e6922f4dfc4f30f1790b61c5 Mon Sep 17 00:00:00 2001 +From: Petr Mensik +Date: Tue, 20 Sep 2022 11:22:47 +0200 +Subject: [PATCH 4/4] Fix CVE-2022-38178 + +5962. [security] Fix memory leak in EdDSA verify processing. + (CVE-2022-38178) [GL #3487] +--- + lib/dns/openssleddsa_link.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/lib/dns/openssleddsa_link.c b/lib/dns/openssleddsa_link.c +index 6a6a74d..3157011 100644 +--- a/lib/dns/openssleddsa_link.c ++++ b/lib/dns/openssleddsa_link.c +@@ -234,11 +234,11 @@ openssleddsa_verify(dst_context_t *dctx, const isc_region_t *sig) { + } + #endif /* if HAVE_OPENSSL_ED448 */ + if (siglen == 0) { +- return (ISC_R_NOTIMPLEMENTED); ++ DST_RET(ISC_R_NOTIMPLEMENTED); + } + + if (sig->length != siglen) { +- return (DST_R_VERIFYFAILURE); ++ DST_RET(DST_R_VERIFYFAILURE); + } + + isc_buffer_usedregion(buf, &tbsreg); +-- +2.37.3 + diff --git a/SPECS/bind.spec b/SPECS/bind.spec index 6e30f0a..0b7246e 100644 --- a/SPECS/bind.spec +++ b/SPECS/bind.spec @@ -51,7 +51,7 @@ Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) serv Name: bind License: MPLv2.0 Version: 9.16.23 -Release: 1%{?dist} +Release: 1%{?dist}.1 Epoch: 32 Url: https://www.isc.org/downloads/bind/ # @@ -101,6 +101,9 @@ Patch157:bind-9.11-fips-tests.patch Patch164:bind-9.11-rh1666814.patch Patch170:bind-9.11-feature-test-named.patch Patch171:bind-9.11-tests-variants.patch +Patch175:bind-9.16-CVE-2022-3080.patch +Patch176:bind-9.16-CVE-2022-38177.patch +Patch177:bind-9.16-CVE-2022-38178.patch %{?systemd_ordering} Requires: coreutils @@ -401,6 +404,9 @@ in HTML and PDF format. %patch164 -p1 -b .rh1666814 %patch170 -p1 -b .featuretest-named %patch171 -p1 -b .test-variant +%patch175 -p1 -b .CVE-2022-3080 +%patch176 -p1 -b .CVE-2022-38177 +%patch177 -p1 -b .CVE-2022-38178 %if %{with PKCS11} %patch135 -p1 -b .config-pkcs11 @@ -1123,6 +1129,11 @@ fi; %endif %changelog +* Thu Sep 22 2022 Petr Menšík - 32:9.16.23-1.1 +- Fix possible serve-stale related crash (CVE-2022-3080) +- Fix memory leak in ECDSA verify processing (CVE-2022-38177) +- Fix memory leak in EdDSA verify processing (CVE-2022-38178) + * Fri Nov 19 2021 Petr Menšík - 32:9.16.23-1 - Update to 9.16.23 (#2024210)