Blame SOURCES/libvirt-qemu-avoid-denial-of-service-reading-from-QEMU-guest-agent-CVE-2018-1064.patch

e6dfe8
From d0b7ef97c4c5fe871664f2a952c8c3b0b4417d23 Mon Sep 17 00:00:00 2001
e6dfe8
Message-Id: <d0b7ef97c4c5fe871664f2a952c8c3b0b4417d23@dist-git>
e6dfe8
From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>
e6dfe8
Date: Thu, 1 Mar 2018 14:55:26 +0000
e6dfe8
Subject: [PATCH] qemu: avoid denial of service reading from QEMU guest agent
e6dfe8
 (CVE-2018-1064)
e6dfe8
MIME-Version: 1.0
e6dfe8
Content-Type: text/plain; charset=UTF-8
e6dfe8
Content-Transfer-Encoding: 8bit
e6dfe8
e6dfe8
We read from the agent until seeing a \r\n pair to indicate a completed
e6dfe8
reply or event. To avoid memory denial-of-service though, we must have a
e6dfe8
size limit on amount of data we buffer. 10 MB is large enough that it
e6dfe8
ought to cope with normal agent replies, and small enough that we're not
e6dfe8
consuming unreasonable mem.
e6dfe8
e6dfe8
This is identical to the flaw we had reading from the QEMU monitor
e6dfe8
as CVE-2018-5748, so rather embarrassing that we forgot to fix
e6dfe8
the agent code at the same time.
e6dfe8
e6dfe8
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
e6dfe8
(cherry picked from commit fbf31e1a4cd19d6f6e33e0937a009775cd7d9513)
e6dfe8
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
e6dfe8
Reviewed-by: Ján Tomko <jtomko@redhat.com>
e6dfe8
---
e6dfe8
 src/qemu/qemu_agent.c | 15 +++++++++++++++
e6dfe8
 1 file changed, 15 insertions(+)
e6dfe8
e6dfe8
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
e6dfe8
index 5d125c4138..9cf767bd8a 100644
e6dfe8
--- a/src/qemu/qemu_agent.c
e6dfe8
+++ b/src/qemu/qemu_agent.c
e6dfe8
@@ -53,6 +53,15 @@ VIR_LOG_INIT("qemu.qemu_agent");
e6dfe8
 #define DEBUG_IO 0
e6dfe8
 #define DEBUG_RAW_IO 0
e6dfe8
 
e6dfe8
+/* We read from QEMU until seeing a \r\n pair to indicate a
e6dfe8
+ * completed reply or event. To avoid memory denial-of-service
e6dfe8
+ * though, we must have a size limit on amount of data we
e6dfe8
+ * buffer. 10 MB is large enough that it ought to cope with
e6dfe8
+ * normal QEMU replies, and small enough that we're not
e6dfe8
+ * consuming unreasonable mem.
e6dfe8
+ */
e6dfe8
+#define QEMU_AGENT_MAX_RESPONSE (10 * 1024 * 1024)
e6dfe8
+
e6dfe8
 /* When you are the first to uncomment this,
e6dfe8
  * don't forget to uncomment the corresponding
e6dfe8
  * part in qemuAgentIOProcessEvent as well.
e6dfe8
@@ -535,6 +544,12 @@ qemuAgentIORead(qemuAgentPtr mon)
e6dfe8
     int ret = 0;
e6dfe8
 
e6dfe8
     if (avail < 1024) {
e6dfe8
+        if (mon->bufferLength >= QEMU_AGENT_MAX_RESPONSE) {
e6dfe8
+            virReportSystemError(ERANGE,
e6dfe8
+                                 _("No complete agent response found in %d bytes"),
e6dfe8
+                                 QEMU_AGENT_MAX_RESPONSE);
e6dfe8
+            return -1;
e6dfe8
+        }
e6dfe8
         if (VIR_REALLOC_N(mon->buffer,
e6dfe8
                           mon->bufferLength + 1024) < 0)
e6dfe8
             return -1;
e6dfe8
-- 
e6dfe8
2.17.0
e6dfe8