Bug#887855: stretch-pu: package libvirt/3.0.0-4+deb9u2

2018-03-02 Thread Adam D. Barratt
Control: tags -1 + pending

On Mon, 2018-02-26 at 12:25 +0100, Guido Günther wrote:
> On Fri, Feb 23, 2018 at 04:42:46PM +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sat, 2018-01-20 at 18:46 +0100, Guido Günther wrote:
> > > the above update addresses CVE-2018-5748 as well as a bug where
> > > disks
> > > with cache=directsync couldn't be migrated (#883208).
> > > 
> > 
> > +_("Migration may lead to data
> > corruption if disks"
> > +- " use cache != none"));
> > ++ " use cache != none or cache !=
> > directsync"));
> > 
> > I think that message should use "and", not "or" - all possible
> > values
> > are "!= none or != directsync". (Or maybe "if disks use cache !=
> > none
> > or directsync" or something.)
> 
> I agree but that's what upstream uses so I optet for leaving it as
> is.

Sure.

> > Please go ahead.
> 
> Uploded. Thanks.
> 

Flagged for acceptance into p-u.

Regards,

Adam



Bug#887855: stretch-pu: package libvirt/3.0.0-4+deb9u2

2018-02-26 Thread Guido Günther
On Fri, Feb 23, 2018 at 04:42:46PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2018-01-20 at 18:46 +0100, Guido Günther wrote:
> > the above update addresses CVE-2018-5748 as well as a bug where disks
> > with cache=directsync couldn't be migrated (#883208).
> > 
> 
> +_("Migration may lead to data corruption if 
> disks"
> +- " use cache != none"));
> ++ " use cache != none or cache != directsync"));
> 
> I think that message should use "and", not "or" - all possible values
> are "!= none or != directsync". (Or maybe "if disks use cache != none
> or directsync" or something.)

I agree but that's what upstream uses so I optet for leaving it as is.

> Please go ahead.

Uploded. Thanks.
 -- Guido



Bug#887855: stretch-pu: package libvirt/3.0.0-4+deb9u2

2018-02-23 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2018-01-20 at 18:46 +0100, Guido Günther wrote:
> the above update addresses CVE-2018-5748 as well as a bug where disks
> with cache=directsync couldn't be migrated (#883208).
> 

+_("Migration may lead to data corruption if disks"
+- " use cache != none"));
++ " use cache != none or cache != directsync"));

I think that message should use "and", not "or" - all possible values
are "!= none or != directsync". (Or maybe "if disks use cache != none
or directsync" or something.)

Please go ahead.

Regards,

Adam



Bug#887855: stretch-pu: package libvirt/3.0.0-4+deb9u2

2018-01-20 Thread Guido Günther
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   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 00..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" 
+Date: Tue, 16 Jan 2018 17:00:11 +
+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 
+---
+ 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 00..01bcc4ca64
--- /dev/null
+++ 
b/debian/patches/qemu-shared-disks-with-cache-directsync-should-be-safe-fo.patch
@@ -0,0 +1,41 @@
+From: Hao Peng 
+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 
+Reviewed-by: Wang Yechao 
+---
+ 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);
+ 
+