~ubuntu-virt/libvirt/+git/libvirt-lp-import:v1.3.3-maint

Last commit made on 2019-06-24
Get this branch:
git clone -b v1.3.3-maint https://git.launchpad.net/~ubuntu-virt/libvirt/+git/libvirt-lp-import

Branch merges

Branch information

Name:
v1.3.3-maint
Repository:
lp:~ubuntu-virt/libvirt/+git/libvirt-lp-import

Recent commits

a663e28... by =?utf-8?q?J=C3=A1n_Tomko?= <email address hidden>

api: disallow virConnectGetDomainCapabilities on read-only connections

This API can be used to execute arbitrary emulators.
Forbid it on read-only connections.

Fixes: CVE-2019-10167
Signed-off-by: Ján Tomko <email address hidden>
Reviewed-by: Daniel P. Berrangé <email address hidden>
(cherry picked from commit 8afa68bac0cf99d1f8aaa6566685c43c22622f26)
Signed-off-by: Ján Tomko <email address hidden>

b22baef... by =?utf-8?q?J=C3=A1n_Tomko?= <email address hidden>

api: disallow virDomainSaveImageGetXMLDesc on read-only connections

The virDomainSaveImageGetXMLDesc API is taking a path parameter,
which can point to any path on the system. This file will then be
read and parsed by libvirtd running with root privileges.

Forbid it on read-only connections.

Fixes: CVE-2019-10161
Reported-by: Matthias Gerstner <email address hidden>
Signed-off-by: Ján Tomko <email address hidden>
Reviewed-by: Daniel P. Berrangé <email address hidden>
(cherry picked from commit aed6a032cead4386472afb24b16196579e239580)
Signed-off-by: Ján Tomko <email address hidden>

Conflicts:
  src/libvirt-domain.c
  src/remote/remote_protocol.x

Upstream commit 12a51f372 which introduced the VIR_DOMAIN_SAVE_IMAGE_XML_SECURE
alias for VIR_DOMAIN_XML_SECURE is not backported.
Just skip the commit since we now disallow the whole API on read-only
connections, regardless of the flag.

Signed-off-by: Ján Tomko <email address hidden>

cad11c9... by Cole Robinson

Prep for release 1.3.3.3

89b75be... by Andrea Bolognani <email address hidden>

virtlogd: Don't stop or restart along with libvirtd

Commit 839a060 tied the lifecycle of virtlogd more
closely to that of libvirtd. Unfortunately, while starting
virtlogd when libvirtd is started is definitely a good idea,
restarting virtlogd or shutting it down at any time outside
of system poweroff is not.

Revert part of that commit by removing the PartOf= lines,
meaning that only startup requests will be propagated from
libvirtd to virtlogd.

Resolves: https://bugzilla.redhat.com/1372576
(cherry picked from commit f496ce1df35df7498bd3d9d7e113bb2eb3e51ba9)

322b703... by Andrea Bolognani <email address hidden>

virtlogd.socket: Tie lifecycle to libvirtd.service

We already guarantee that virtlogd.socket is enabled/disabled
along with libvirtd.service, but if libvirtd.service has just
been installed and is started before rebooting, then
virtlogd.socket will not be running and guest startup will
fail.

Add Requires=virtlogd.socket to libvirtd.service to make sure
virtlogd.socket is always started along with libvirtd.service,
and add Before=libvirtd.service to both virtlogd.socket and
virtlogd.service so that virtlogd never disappears before
libvirtd has exited.

Also add PartOf=libvirtd.service to both virtlogd.socket and
virtlogd.service, so that virtlogd can be shut down when not
needed.

Resolves: https://bugzilla.redhat.com/1372576
(cherry picked from commit 839a060890d8b2408c0ea20e3c5997c7b2a4a079)

c7d6d5a... by Michal Privoznik <email address hidden>

schema: Don't validate paths

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

On UNIX like systems there are no constraints on what characters
can be in file/dir names (except for NULL, obviously). Moreover,
some values that we think of as paths (e.g. disk source) are not
necessarily paths at all. For instance, some hypervisors take
that as an arbitrary identifier and corresponding file is then
looked up by hypervisor in its table. Instead of trying to fix
our regular expressions (and forgetting to include yet another
character there), lets drop the validation completely.

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

8123b6b... by Pavel Hrdina <email address hidden>

maint: fix syntax-check sc_prohibit_int_ijk exclude rule

Fix the regex for excluding files for this syntax-rule. The rule "include/"
will not work, because we are matching the whole line like this
"^(...|include/|...)$ so we need to use "include/libvirt/libvirt.+". The second
issue is that we are using only one '$' but there should be two of those at the
end. The last small adjustment is to escape dots '.' so it match only dot.

Signed-off-by: Pavel Hrdina <email address hidden>
(cherry picked from commit a94efa50e253cb59a2925dca2705bce801f46fb1)

8f2b4e3... by Marc Hartmayer <email address hidden>

util: bitmap: clarify virBitmapLastSetBit() behavior for empty bitmaps

Before the variable 'bits' was initialized with 0 (commit
3470cd860d517760b13e26d97b6a842ff72687a1), the following bug was
possible.

A function call with an empty bitmap leads to undefined
behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0
and 'sz == 1'. So the non global and non static variable 'bits' would
have never been set. Consequently the check 'bits == 0' results in
undefined behavior.

This patch clarifies the current version of the function by handling the
empty bitmap explicitly. Also, for an empty bitmap there is obviously no
bit set so we can just return -1 (indicating no bit set) right away. The
explicit check for 'bits == 0' after the loop is unnecessary because we
only get to this point if no set bit was found.

Reviewed-by: Boris Fiuczynski <email address hidden>
Reviewed-by: Sascha Silbe <email address hidden>
Reviewed-by: Bjoern Walk <email address hidden>
Signed-off-by: Marc Hartmayer <email address hidden>
(cherry picked from commit 7cd01a248b3995909adad29a6edbe76d3d16510f)

942b6ab... by Martin Kletzander

Fix building with -Og

When building using -Og, gcc sees that some variables can be used
uninitialized It can be debatable whether it is possible with our
codeflow, but functions should be self-contained and initializations are
always good. The return instead of goto is due to actualType being used
in the cleanup.

Signed-off-by: Martin Kletzander <email address hidden>
(cherry picked from commit 3470cd860d517760b13e26d97b6a842ff72687a1)

7fdce1e... by Martin Kletzander

qemu: Only use memory-backend-file with NUMA if needed

If this reminds you of a commit message from around a year ago, it's
41c2aa729f0af084ede95ee9a06219a2dd5fb5df and yes, we're dealing with
"the same thing" again. Or f309db1f4d51009bad0d32e12efc75530b66836b and
it's similar.

There is a logic in place that if there is no real need for
memory-backend-file, qemuBuildMemoryBackendStr() returns 0. However
that wasn't the case with hugepage backing. The reason for that was
that we abused the 'pagesize' variable for storing that information, but
we should rather have a separate one that specifies whether we really
need the new object for hugepage backing. And that variable should be
set only if this particular NUMA cell needs special treatment WRT
hugepages.

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

Signed-off-by: Martin Kletzander <email address hidden>
(cherry picked from commit 4372a7845acbc6974f6027ef68e7dd3eeb47f425)