~ubuntu-virt/libvirt/+git/libvirt-lp-import:v0.9.12-maint

Last commit made on 2016-06-30
Get this branch:
git clone -b v0.9.12-maint https://git.launchpad.net/~ubuntu-virt/libvirt/+git/libvirt-lp-import

Branch merges

Branch information

Name:
v0.9.12-maint
Repository:
lp:~ubuntu-virt/libvirt/+git/libvirt-lp-import

Recent commits

eea38b5... by Jiri Denemark <email address hidden>

qemu: Let empty default VNC password work as documented

CVE-2016-5008

Setting an empty graphics password is documented as a way to disable
VNC/SPICE access, but QEMU does not always behaves like that. VNC would
happily accept the empty password. Let's enforce the behavior by setting
password expiration to "now".

https://bugzilla.redhat.com/show_bug.cgi?id=1180092

Signed-off-by: Jiri Denemark <email address hidden>
(cherry picked from commit bb848feec0f3f10e92dd8e5231ae7aa89b5598f3)
(cherry picked from commit d933f68ee660566b52cd90330aee0d5f414636a4)
(cherry picked from commit 139a4265774b7aa194f8479a82188bc1337cd7a4)

7502800... by Peter Krempa

CVE-2014-3633: qemu: blkiotune: Use correct definition when looking up disk

Live definition was used to look up the disk index while persistent one
was indexed leading to a crash in qemuDomainGetBlockIoTune. Use the
correct def and report a nice error.

Unfortunately it's accessible via read-only connection, though it can
only crash libvirtd in the cases where the guest is hot-plugging disks
without reflecting those changes to the persistent definition. So
avoiding hotplug, or doing hotplug where persistent is always modified
alongside live definition, will avoid the out-of-bounds access.

Introduced in: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa (v0.9.8)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140724
Reported-by: Luyao Huang <email address hidden>
Signed-off-by: Peter Krempa <email address hidden>

(cherry picked from commit 3e745e8f775dfe6f64f18b5c2fe4791b35d3546b)

Conflicts:
 src/qemu/qemu_driver.c - context due to fewer functions

022b34c... by Daniel Berrange

LSN-2014-0003: Don't expand entities when parsing XML

If the XML_PARSE_NOENT flag is passed to libxml2, then any
entities in the input document will be fully expanded. This
allows the user to read arbitrary files on the host machine
by creating an entity pointing to a local file. Removing
the XML_PARSE_NOENT flag means that any entities are left
unchanged by the parser, or expanded to "" by the XPath
APIs.

Signed-off-by: Daniel P. Berrange <email address hidden>
(cherry picked from commit d6b27d3e4c40946efa79e91d134616b41b1666c4)

800eb5a... by Michal Privoznik <email address hidden>

virNetClientSetTLSSession: Restore original signal mask

Currently, we use pthread_sigmask(SIG_BLOCK, ...) prior to calling
poll(). This is okay, as we don't want poll() to be interrupted.
However, then - immediately as we fall out from the poll() - we try to
restore the original sigmask - again using SIG_BLOCK. But as the man
page says, SIG_BLOCK adds signals to the signal mask:

SIG_BLOCK
      The set of blocked signals is the union of the current set and the set argument.

Therefore, when restoring the original mask, we need to completely
overwrite the one we set earlier and hence we should be using:

SIG_SETMASK
      The set of blocked signals is set to the argument set.

Signed-off-by: Michal Privoznik <email address hidden>
(cherry picked from commit 3d4b4f5ac634c123af1981084add29d3a2ca6ab0)

2da26d3... by Eric Blake

build: use proper pod for nested bulleted VIRSH_DEBUG list

Newer pod (hello rawhide) complains if you attempt to mix bullets
and non-bullets in the same list:

virsh.pod around line 3177: Expected text after =item, not a bullet

As our intent was to nest an inner list, we make that explicit to
keep pod happy.

* tools/virsh.pod (ENVIRONMENT): Use correct pod syntax.

(cherry picked from commit 00d69b4af1215695ebfc8f1dbfa77804c2b293fd)

0595648... by Guido Günther

Prepare for 0.9.12.3

c385db5... by Jiri Denemark <email address hidden>

Really don't crash if a connection closes early

https://bugzilla.redhat.com/show_bug.cgi?id=1047577

When writing commit 173c291, I missed the fact virNetServerClientClose
unlocks the client object before actually clearing client->sock and thus
it is possible to hit a window when client->keepalive is NULL while
client->sock is not NULL. I was thinking client->sock == NULL was a
better check for a closed connection but apparently we have to go with
client->keepalive == NULL to actually fix the crash.

Signed-off-by: Jiri Denemark <email address hidden>
(cherry picked from commit 066c8ef6c18bc1faf8b3e10787b39796a7a06cc0)

ffdb640... by Jiri Denemark <email address hidden>

Don't crash if a connection closes early

https://bugzilla.redhat.com/show_bug.cgi?id=1047577

When a client closes its connection to libvirtd early during
virConnectOpen, more specifically just after making
REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if
VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for
the result, libvirtd may crash due to a race in keep-alive
initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE
call, the daemon's event loop delegates it to a worker thread. In case
the event loop detects EOF on the connection and calls
virNetServerClientClose before the worker thread starts to handle
REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be
disposed by the time virNetServerClientStartKeepAlive gets called from
remoteDispatchConnectSupportsFeature. Because the flow is common for
both authenticated and read-only connections, even unprivileged clients
may cause the daemon to crash.

To avoid the crash, virNetServerClientStartKeepAlive needs to check if
the connection is still open before starting keep-alive protocol.

Every libvirt release since 0.9.8 is affected by this bug.

(cherry picked from commit 173c2914734eb5c32df6d35a82bf503e12261bcf)

Conflicts:
 src/rpc/virnetserverclient.c - older locking style

2786686... by Jiri Denemark <email address hidden>

qemu: Fix job usage in virDomainGetBlockIoTune

CVE-2013-6458

Every API that is going to begin a job should do that before fetching
data from vm->def.

Conflicts:
 src/qemu/qemu_driver.c

(cherry picked from commit 3b56425938e2f97208d5918263efa0d6439e4ecd)

3e7d9e5... by Jiri Denemark <email address hidden>

qemu: Fix job usage in qemuDomainBlockJobImpl

CVE-2013-6458

Every API that is going to begin a job should do that before fetching
data from vm->def.

Conflicts:
        src/qemu/qemu_driver.c

(cherry picked from commit f93d2caa070f6197ab50d372d286018b0ba6bbd8)