Blame SOURCES/bind-9.11-CVE-2021-25215.patch

26e2e4
From 6fc38d1c75ce5a6172267e6ca162c4fdc09657ad Mon Sep 17 00:00:00 2001
26e2e4
From: Petr Mensik <pemensik@redhat.com>
26e2e4
Date: Tue, 27 Apr 2021 10:56:12 +0200
26e2e4
Subject: [PATCH 2/2] CVE-2021-25215
26e2e4
26e2e4
5616.	[security]	named crashed when a DNAME record placed in the ANSWER
26e2e4
			section during DNAME chasing turned out to be the final
26e2e4
			answer to a client query. (CVE-2021-25215) [GL #2540]
26e2e4
---
26e2e4
 bin/named/query.c | 13 ++++++++++---
26e2e4
 1 file changed, 10 insertions(+), 3 deletions(-)
26e2e4
26e2e4
diff --git a/bin/named/query.c b/bin/named/query.c
26e2e4
index a95f5ad..11a888e 100644
26e2e4
--- a/bin/named/query.c
26e2e4
+++ b/bin/named/query.c
26e2e4
@@ -9301,10 +9301,17 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
26e2e4
 		if (noqname != NULL)
26e2e4
 			query_addnoqnameproof(client, noqname);
26e2e4
 		/*
26e2e4
-		 * We shouldn't ever fail to add 'rdataset'
26e2e4
-		 * because it's already in the answer.
26e2e4
+		 * 'rdataset' will only be non-NULL here if the ANSWER section
26e2e4
+		 * of the message to be sent to the client already contains an
26e2e4
+		 * RRset with the same owner name and the same type as
26e2e4
+		 * 'rdataset'.  This should never happen, with one exception:
26e2e4
+		 * when chasing DNAME records, one of the DNAME records placed
26e2e4
+		 * in the ANSWER section may turn out to be the final answer to
26e2e4
+		 * the client's query, but we have no way of knowing that until
26e2e4
+		 * now.  In such a case, 'rdataset' will be freed later, so we
26e2e4
+		 * do not need to free it here.
26e2e4
 		 */
26e2e4
-		INSIST(rdataset == NULL);
26e2e4
+		INSIST(rdataset == NULL || qtype == dns_rdatatype_dname);
26e2e4
 	}
26e2e4
 
26e2e4
  addauth:
26e2e4
-- 
26e2e4
2.26.3
26e2e4