[kirkstone,1/1] bind: fix CVE-2023-2911

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.urade@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

There is already a fix for this CVE in kirkstone:

https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=08810d3fe6988ea821805eca16105b4632335654

Steve

On Thu, Jul 20, 2023 at 8:50 PM Urade, Yogita via lists.openembedded.org
<Yogita.Urade=windriver.com@lists.openembedded.org> wrote:

> 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.urade@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 <mnowak@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.urade@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/3620601
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> steve@sakoman.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>