If the `recursive-clients` quota is reached on a BIND 9 resolver
configured with both `stale-answer-enable yes;` and
`stale-answer-client-timeout 0;`, a sequence of serve-stale-related
lookups could cause `named` to loop and terminate unexpectedly due
to a stack overflow.
This issue affects BIND 9 versions 9.16.33 through 9.16.41, 9.18.7
through 9.18.15, 9.16.33-S1 through 9.16.41-S1, and 9.18.11-S1
through 9.18.15-S1.

References:
https://kb.isc.org/docs/cve-2023-2911
https://downloads.isc.org/isc/bind9/9.18.16/doc/arm/html/notes.html#notes-for-bind-9-18-16

Signed-off-by: Yogita Urade <yogita.ur...@windriver.com>
---
 .../bind/bind-9.18.11/CVE-2023-2911.patch     | 109 ++++++++++++++++++
 .../recipes-connectivity/bind/bind_9.18.11.bb |   1 +
 2 files changed, 110 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bind/bind-9.18.11/CVE-2023-2911.patch

diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/CVE-2023-2911.patch 
b/meta/recipes-connectivity/bind/bind-9.18.11/CVE-2023-2911.patch
new file mode 100644
index 0000000000..729d13ee18
--- /dev/null
+++ b/meta/recipes-connectivity/bind/bind-9.18.11/CVE-2023-2911.patch
@@ -0,0 +1,109 @@
+From 2d6982985021ee354469a0fc380008d6c6fa8ae2 Mon Sep 17 00:00:00 2001
+From: Michal Nowak <mno...@isc.org>
+Date: Thu, 20 Jul 2023 08:07:32 +0000
+Subject: [PATCH] Merge branch '4089-confidential-stale-query-loop-bind-9.18'
+ into 'security-bind-9.18'
+
+[9.18][CVE-2023-2911] Fix stale-answer-client-timeout 0 crash
+
+See merge request isc-private/bind9!523
+
+CVE-2023-2911
+
+Upstream-Status: Backport 
[https://gitlab.isc.org/isc-projects/bind9/-/commit/2d6982985021ee354469a0fc380008d6c6fa8ae2]
+
+Signed-off-by: Yogita Urade <yogita.ur...@windriver.com>
+---
+ CHANGES        |  7 +++++++
+ lib/ns/query.c | 29 +++++++++++++++++++++--------
+ 2 files changed, 28 insertions(+), 8 deletions(-)
+
+diff --git a/CHANGES b/CHANGES
+index ca2f3a3..0e18f27 100644
+--- a/CHANGES
++++ b/CHANGES
+@@ -1,3 +1,10 @@
++6192. [security]      A query that prioritizes stale data over lookup
++                      triggers a fetch to refresh the stale data in cache.
++                      If the fetch is aborted for exceeding the recursion
++                      quota, it was possible for 'named' to enter an infinite
++                      callback loop and crash due to stack overflow. This has
++                      been fixed. (CVE-2023-2911) [GL #4089]
++
+       --- 9.18.11 released ---
+
+ 6067. [security]      Fix serve-stale crash when recursive clients soft quota
+diff --git a/lib/ns/query.c b/lib/ns/query.c
+index 0d2ba6b..7a812e6 100644
+--- a/lib/ns/query.c
++++ b/lib/ns/query.c
+@@ -5824,6 +5824,7 @@ query_refresh_rrset(query_ctx_t *orig_qctx) {
+       qctx.client->query.dboptions &= ~(DNS_DBFIND_STALETIMEOUT |
+                                         DNS_DBFIND_STALEOK |
+                                         DNS_DBFIND_STALEENABLED);
++      qctx.client->nodetach = false;
+
+       /*
+        * We'll need some resources...
+@@ -6076,7 +6077,13 @@ query_lookup(query_ctx_t *qctx) {
+                                       "%s stale answer used, an attempt to "
+                                       "refresh the RRset will still be made",
+                                       namebuf);
++
+                               qctx->refresh_rrset = STALE(qctx->rdataset);
++                              /*
++                               * If we are refreshing the RRSet, we must not
++                               * detach from the client in query_send().
++                               */
++                              qctx->client->nodetach = qctx->refresh_rrset;
+                               ns_client_extendederror(
+                                       qctx->client, ede,
+                                       "stale data prioritized over lookup");
+@@ -6503,7 +6510,7 @@ ns_query_recurse(ns_client_t *client, dns_rdatatype_t 
qtype, dns_name_t *qname,
+       if (recparam_match(&client->query.recparam, qtype, qname, qdomain)) {
+               ns_client_log(client, NS_LOGCATEGORY_CLIENT, NS_LOGMODULE_QUERY,
+                             ISC_LOG_INFO, "recursion loop detected");
+-              return (ISC_R_FAILURE);
++              return (ISC_R_ALREADYRUNNING);
+       }
+
+       recparam_update(&client->query.recparam, qtype, qname, qdomain);
+@@ -7620,10 +7627,21 @@ query_usestale(query_ctx_t *qctx, isc_result_t result) 
{
+               return (false);
+       }
+
+-      if (result == DNS_R_DUPLICATE || result == DNS_R_DROP) {
++      if (qctx->refresh_rrset) {
++              /*
++               * This is a refreshing query, we have already prioritized
++               * stale data, so don't enable serve-stale again.
++               */
++              return (false);
++      }
++
++      if (result == DNS_R_DUPLICATE || result == DNS_R_DROP ||
++          result == ISC_R_ALREADYRUNNING)
++      {
+               /*
+                * Don't enable serve-stale if the result signals a duplicate
+-               * query or query that is being dropped.
++               * query or a query that is being dropped or can't proceed
++               * because of a recursion loop.
+                */
+               return (false);
+       }
+@@ -11927,12 +11945,7 @@ 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);
+
+--
+2.40.0
diff --git a/meta/recipes-connectivity/bind/bind_9.18.11.bb 
b/meta/recipes-connectivity/bind/bind_9.18.11.bb
index 0618129318..4349b6441b 100644
--- a/meta/recipes-connectivity/bind/bind_9.18.11.bb
+++ b/meta/recipes-connectivity/bind/bind_9.18.11.bb
@@ -18,6 +18,7 @@ SRC_URI = 
"https://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.xz \
            file://bind-ensure-searching-for-json-headers-searches-sysr.patch \
            file://0001-named-lwresd-V-and-start-log-hide-build-options.patch \
            file://0001-avoid-start-failure-with-bind-user.patch \
+           file://CVE-2023-2911.patch \
            "
 
 SRC_URI[sha256sum] = 
"8ff3352812230cbcbda42df87cad961f94163d3da457c5e4bef8057fd5df2158"
-- 
2.40.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184671): 
https://lists.openembedded.org/g/openembedded-core/message/184671
Mute This Topic: https://lists.openembedded.org/mt/100272152/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to