Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian....@packages.debian.org
Usertags: pu
Hi,
the above update addresses CVE-2018-5748 as well as a bug where disks
with cache=directsync couldn't be migrated (#883208).
O.k. to upload to stretch-pu?
Cheers,
-- Guido
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500,
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 222b31e543..f9aca519eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libvirt (3.0.0-4+deb9u2) stretch; urgency=medium
+
+ * CVE-2018-5748: qemu: avoid denial of service reading from QEMU monitor
+ (Closes: #887700)
+ * qemu: shared disks with cache=directsync should be safe for migration.
+ Thanks to Carsten Burkhardt (Closes: #883208)
+
+ -- Guido Günther <a...@sigxcpu.org> Sat, 20 Jan 2018 17:51:39 +0100
+
libvirt (3.0.0-4+deb9u1) stretch-security; urgency=high
* CVE-2017-1000256: qemu: ensure TLS clients always verify the server
diff --git
a/debian/patches/qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
b/debian/patches/qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
new file mode 100644
index 0000000000..5d675ae6c3
--- /dev/null
+++
b/debian/patches/qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
@@ -0,0 +1,49 @@
+From: "Daniel P. Berrange" <berra...@redhat.com>
+Date: Tue, 16 Jan 2018 17:00:11 +0000
+Subject: qemu: avoid denial of service reading from QEMU monitor
+ (CVE-2018-5748)
+
+We read from QEMU until seeing a \r\n pair to indicate a completed reply
+or event. To avoid memory denial-of-service though, we must have a size
+limit on amount of data we buffer. 10 MB is large enough that it ought
+to cope with normal QEMU replies, and small enough that we're not
+consuming unreasonable mem.
+
+Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
+---
+ src/qemu/qemu_monitor.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
+index 1610ae3..86ce2d1 100644
+--- a/src/qemu/qemu_monitor.c
++++ b/src/qemu/qemu_monitor.c
+@@ -55,6 +55,15 @@ VIR_LOG_INIT("qemu.qemu_monitor");
+ #define DEBUG_IO 0
+ #define DEBUG_RAW_IO 0
+
++/* We read from QEMU until seeing a \r\n pair to indicate a
++ * completed reply or event. To avoid memory denial-of-service
++ * though, we must have a size limit on amount of data we
++ * buffer. 10 MB is large enough that it ought to cope with
++ * normal QEMU replies, and small enough that we're not
++ * consuming unreasonable mem.
++ */
++#define QEMU_MONITOR_MAX_RESPONSE (10 * 1024 * 1024)
++
+ struct _qemuMonitor {
+ virObjectLockable parent;
+
+@@ -565,6 +574,12 @@ qemuMonitorIORead(qemuMonitorPtr mon)
+ int ret = 0;
+
+ if (avail < 1024) {
++ if (mon->bufferLength >= QEMU_MONITOR_MAX_RESPONSE) {
++ virReportSystemError(ERANGE,
++ _("No complete monitor response found in %d
bytes"),
++ QEMU_MONITOR_MAX_RESPONSE);
++ return -1;
++ }
+ if (VIR_REALLOC_N(mon->buffer,
+ mon->bufferLength + 1024) < 0)
+ return -1;
diff --git
a/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
b/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
new file mode 100644
index 0000000000..01bcc4ca64
--- /dev/null
+++
b/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
@@ -0,0 +1,41 @@
+From: Hao Peng <peng.h...@zte.com.cn>
+Date: Sat, 15 Jul 2017 23:01:25 +0800
+Subject: qemu: shared disks with cache=directsync should be safe for
+ migration
+
+At present shared disks can be migrated with either readonly or cache=none. But
+cache=directsync should be safe for migration, because both cache=directsync
and cache=none
+don't use the host page cache, and cache=direct write through qemu block layer
cache.
+
+Signed-off-by: Peng Hao <peng.h...@zte.com.cn>
+Reviewed-by: Wang Yechao <wang.yechao...@zte.com.cn>
+---
+ src/qemu/qemu_migration.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
+index 0f4a6cf..dba5897 100644
+--- a/src/qemu/qemu_migration.c
++++ b/src/qemu/qemu_migration.c
+@@ -2375,9 +2375,10 @@ qemuMigrationIsSafe(virDomainDefPtr def,
+ const char *src = virDomainDiskGetSource(disk);
+
+ /* Our code elsewhere guarantees shared disks are either readonly (in
+- * which case cache mode doesn't matter) or used with cache=none */
++ * which case cache mode doesn't matter) or used with cache=none or
used with cache=directsync */
+ if (qemuMigrateDisk(disk, nmigrate_disks, migrate_disks) &&
+- disk->cachemode != VIR_DOMAIN_DISK_CACHE_DISABLE) {
++ disk->cachemode != VIR_DOMAIN_DISK_CACHE_DISABLE &&
++ disk->cachemode != VIR_DOMAIN_DISK_CACHE_DIRECTSYNC) {
+ int rc;
+
+ if (virDomainDiskGetType(disk) == VIR_STORAGE_TYPE_FILE) {
+@@ -2396,7 +2397,7 @@ qemuMigrationIsSafe(virDomainDefPtr def,
+
+ virReportError(VIR_ERR_MIGRATE_UNSAFE, "%s",
+ _("Migration may lead to data corruption if disks"
+- " use cache != none"));
++ " use cache != none or cache != directsync"));
+ return false;
+ }
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 64cdf94d02..9dd43e33bf 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -23,3 +23,5 @@
CVE-2017-2635-qemu-Don-t-update-physical-storage-size-of-.patch
apparmor-allow-usr-lib-qemu-qemu-bridge-helper.patch
qemu-skip-QMP-probing-of-CPU-definitions-when-missing.patch
security/qemu-ensure-TLS-clients-always-verify-the-server-certific.patch
+qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
+qemu-avoid-denial-of-service-reading-from-QEMU-monitor-CV.patch
