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=1180092Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit bb848fee)
(cherry picked from commit d933f68e)
(cherry picked from commit 139a4265)

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: eca96694a (v0.9.8)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140724Reported-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

(cherry picked from commit 3e745e8f)

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

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: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6b27d3e)

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: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 3d4b4f5a)

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 00d69b4a)

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

When writing commit 173c2914, 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: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 066c8ef6)

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 173c2914)

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

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 3b564259)

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 f93d2caa)

CVE-2013-6458

Generally, every API that is going to begin a job should do that before
fetching data from vm->def. However, qemuDomainGetBlockInfo does not
know whether it will have to start a job or not before checking vm->def.
To avoid using disk alias that might have been freed while we were
waiting for a job, we use its copy. In case the disk was removed in the
meantime, we will fail with "cannot find statistics for device '...'"
error message.

Conflicts:
	src/qemu/qemu_driver.c

(cherry picked from commit b7992595)

CVE-2013-6458
https://bugzilla.redhat.com/show_bug.cgi?id=1043069

When virDomainDetachDeviceFlags is called concurrently to
virDomainBlockStats: libvirtd may crash because qemuDomainBlockStats
finds a disk in vm->def before getting a job on a domain and uses the
disk pointer after getting the job. However, the domain in unlocked
while waiting on a job condition and thus data behind the disk pointer
may disappear. This happens when thread 1 runs
virDomainDetachDeviceFlags and enters monitor to actually remove the
disk. Then another thread starts running virDomainBlockStats, finds the
disk in vm->def, and while it's waiting on the job condition (owned by
the first thread), the first thread finishes the disk removal. When the
second thread gets the job, the memory pointed to be the disk pointer is
already gone.

That said, 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 db86da5c)

Nearly every source file does something like

  #define VIR_FROM_THIS VIR_FROM_FOO
  #define virFooReportErorr(code, ...) \
     virReportErrorHelper(VIR_FROM_THIS, code,  __FILE__,    \
                          __FUNCTION__, __LINE__, \
                          __VA_ARGS__)

This creates needless duplication and inconsistent error
reporting function names in each file. It is trivial to
just have virterror_internal.h provide a virReportError
macro that is equivalent

* src/util/virterror_internal.h: Define virReportError(code, ...)
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

(cherry picked from commit 7e94acd4)

The surest way to avoid regressions is to test documented behavior :)

* tests/virstringtest.c (testStrdup): New test case.
Signed-off-by: NEric Blake <eblake@redhat.com>

(cherry picked from commit 504b4a8d)

While reviewing proposed VIR_STRDUP conversions, I've already noticed
several places that do:

if (str && VIR_STRDUP(dest, str) < 0)

which can be simplified by allowing str to be NULL (something that
strdup() doesn't allow).  Meanwhile, code that wants to ensure a
non-NULL dest regardless of the source can check for <= 0.

Also, make it part of the VIR_STRDUP contract that macro arguments
are evaluated exactly once.

* src/util/virstring.h (VIR_STRDUP, VIR_STRDUP_QUIET, VIR_STRNDUP)
(VIR_STRNDUP_QUIET): Improve contract.
* src/util/virstring.c (virStrdup, virStrndup): Change return
conventions.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	HACKING
	docs/hacking.html.in

(cherry picked from commit 6b74a9f5)

The code adaptation is not done right now, but in subsequent patches.
Hence I am not implementing syntax-check rule as it would break
compilation. Developers are strongly advised to use these new macros.
They are similar to VIR_ALLOC() logic: VIR_STRDUP(dst, src) returns zero
on success, -1 otherwise. In case you don't want to report OOM error,
use the _QUIET variant of a macro.

Conflicts:
	src/libvirt_private.syms
	src/util/virstring.h

(cherry picked from commit c3abb5c4)

Introduced by 7b87a3
When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT,
I got error like:
"libvirt: XML-RPC error : internal error: domain event 0 not registered".
Then I add the following code, it fixed.
Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 9712c251)

Conflicts:
	src/remote/remote_driver.c - context

Done by 'git merge -s ours v0.9.12.1', so that the maint branch
will contain all release tags.
Signed-off-by: NEric Blake <eblake@redhat.com>

Since cbcb1983 we need viratomic.h in
the distributed tarball as well. This fixes "make distcheck".

The 'stats' variable was not initialized to NULL, so if some
early validation of the RPC call fails, it is possible to jump
to the 'cleanup' label and VIR_FREE an uninitialized pointer.
This is a security flaw, since the API can be called from a
readonly connection which can trigger the validation checks.

This was introduced in release v0.9.1 onwards by

  commit 158ba873
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Apr 13 16:21:35 2011 +0100

    Merge all returns paths from dispatcher into single path
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e7f400a1)

Conflicts:
	daemon/remote.c - context

With the existing pkcheck (pid, start time) tuple for identifying
the process, there is a race condition, where a process can make
a libvirt RPC call and in another thread exec a setuid application,
causing it to change to effective UID 0. This in turn causes polkit
to do its permission check based on the wrong UID.

To address this, libvirt must get the UID the caller had at time
of connect() (from SO_PEERCRED) and pass a (pid, start time, uid)
triple to the pkcheck program.

This fix requires that libvirt is re-built against a version of
polkit that has the fix for its CVE-2013-4288, so that libvirt
can see 'pkg-config --variable pkcheck_supports_uid polkit-gobject-1'
Signed-off-by: NColin Walters <walters@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 922b7fda)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	configure.ac - context
	libvirt.spec.in - context of indentation
	src/access/viraccessdriverpolkit.c - not present on this branch

Since PIDs can be reused, polkit prefers to be given
a (PID,start time) pair. If given a PID on its own,
it will attempt to lookup the start time in /proc/pid/stat,
though this is subject to races.

It is safer if the client app resolves the PID start
time itself, because as long as the app has the client
socket open, the client PID won't be reused.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 979e9c56)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/libvirt_private.syms - not backported
	src/locking/lock_daemon.c - not backported
	src/rpc/virnetserverclient.c
	src/rpc/virnetsocket.c
	src/rpc/virnetsocket.h
	src/util/viridentity.h - not backported
	src/util/virprocess.c
	src/util/virprocess.h
	src/util/virstring.c
	src/util/virstring.h

Most conflicts were contextual (this patch adds new functions,
but upstream intermediate patches not backported here also added
new features, and the resolution was picking out just the portions
needed by this commit).  virnetsocket.c also had slightly
different locking semantics.

Continue consolidation of process functions by moving some
helpers out of command.{c,h} into virprocess.{c,h}
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 9467ab60)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/lxc/lxc_controller.c
	src/util/command.c
	src/util/virprocess.c
	tests/testutils.c

There are a number of process related functions spread
across multiple files. Start to consolidate them by
creating a virprocess.{c,h} file
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e5e2b65c)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/qemu/qemu_monitor.c
	src/util/util.h

The virCommand prefix was inappropriate because the API
does not use any virCommandPtr object instance. This
API closely related to waitpid/exit, so use virProcess
as the prefix
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 49ecf8b4)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/util/command.c

Change "Pid" to "Process" to align with the virProcessKill
API naming prefix
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 0fb58ef5)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/util/util.c
	src/lxc/lxc_container.c
	src/lxc/lxc_controller.c

Changing naming to follow the convention of "object" followed
by "action"
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit cf470068)

This introduces a few new APIs for dealing with strings.
One to split a char * into a char **, another to join a
char ** into a char *, and finally one to free a char **

There is a simple test suite to validate the edge cases
too. No more need to use the horrible strtok_r() API,
or hand-written code for splitting strings.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 76c1fd33)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	tests/Makefile.am - several intermediate tests not backported

When given a CA cert with basic constraints to set non-critical,
and key usage of 'key signing', this should be rejected. Version
of GNUTLS < 3 do not rejecte it though, so we never noticed the
test case was broken
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 0204d6d7)

Make has a builtin operator 'undefine', and coupled with latest
automake.git, this test name ended up confusing make into thinking
the file name was meant to be used as the make operator.  Renaming
the file avoids the confusion.

* tests/undefine: Rename...
* tests/virsh-undefine: ...to this.
* tests/Makefile.am (test_scripts): Use new name.
Reported by Jim Meyering.

(cherry picked from commit a20f06d9)

The first two hunks fix "Unterminated I<...> sequence" error and the
last one fixes "’=item’ outside of any ’=over’" error.

(cherry picked from commit 61299a1c)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	tools/virsh.pod - drop hunks not present this far back

This is a second attempt at fixing the problem first attempted
in commit 2df8d991; basically undoing the fact that it was
reverted in commit 43cee32f, plus fixing two more issues: the
code in configure.ac has to EXACTLY match virnetdevbridge.c
with regards to declaring in6 types before using if_bridge.h,
and the fact that RHEL 5 has even more conflicts:

In file included from util/virnetdevbridge.c:49:
/usr/include/linux/in6.h:47: error: conflicting types for 'in6addr_any'
/usr/include/netinet/in.h:206: error: previous declaration of 'in6addr_any' was here
/usr/include/linux/in6.h:49: error: conflicting types for 'in6addr_loopback'
/usr/include/netinet/in.h:207: error: previous declaration of 'in6addr_loopback' was here

The rest of this commit message borrows from the original try
of 2df8d991:

A fresh checkout on a RHEL 6 machine with these packages:
kernel-headers-2.6.32-405.el6.x86_64
glibc-2.12-1.128.el6.x86_64
failed to configure with this message:
checking for linux/if_bridge.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support

Digging in config.log, we see that the problem is identical to
what we fixed earlier in commit d12c2811:

configure:98831: checking for linux/if_bridge.h
configure:98853: gcc -std=gnu99 -c -g -O2  conftest.c >&5
In file included from /usr/include/linux/if_bridge.h:17,
                 from conftest.c:559:
/usr/include/linux/in6.h:31: error: redefinition of 'struct in6_addr'
/usr/include/linux/in6.h:48: error: redefinition of 'struct sockaddr_in6'
/usr/include/linux/in6.h:56: error: redefinition of 'struct ipv6_mreq'
configure:98860: $? = 1

I had not hit it earlier because I was using incremental builds,
where config.cache had shielded me from the kernel-headers breakage.

* configure.ac (if_bridge.h): Avoid conflicting type definitions.
* src/util/virnetdevbridge.c (includes): Also sanitize for RHEL 5.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 70024dc9)

Done in one patch rather than a series for bisectability reasons
(as intermediate patches suffer from various problems on various
platforms), and because the intermediate patches include a revert,
but it is pointless to backport two patches where one undoes the
other.  Intermediate patches include: 9a2f36ec, c308a9ae, 1bf661ca,
d12c2811, 2df8d991, 43cee32f (phew, that's a mouthful).

Conflicts:
	configure.ac - skip the churn of all intermediate patches
	src/util/virnetdevbridge.c - ditto

glibc 2.15 (on Fedora 17) coupled with explicit disabling of
optimization during development dies a painful death:

In file included from /usr/include/limits.h:27:0,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/limits.h:169,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/limits.h:34,
                 from util/bitmap.c:26:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
cc1: all warnings being treated as errors

Work around this by only conditionally defining _FORTIFY_SOURCE,
in the case where glibc can actually use it.  The trick is using
AH_VERBATIM instead of AC_DEFINE.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Squelch
_FORTIFY_SOURCE when needed to avoid glibc #warnings.

(cherry picked from commit 2af63b1c)

When running virDomainDestroy, we need to make sure that no other
background thread cleans up the domain while we're doing our work.
This can happen if we release the domain object while in the
middle of work, because the monitor might detect EOF in this window.
For this reason we have a 'beingDestroyed' flag to stop the monitor
from doing its normal cleanup. Unfortunately this flag was only
being used to protect qemuDomainBeginJob, and not qemuProcessKill

This left open a race condition where either libvirtd could crash,
or alternatively report bogus error messages about the domain already
having been destroyed to the caller
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 81621f3e)

Conflicts:
	src/qemu/qemu_driver.c

When calling qemuProcessKill from the virDomainDestroy impl
in QEMU, do not ignore the return value. This ensures that
if QEMU fails to respond to SIGKILL, the caller will know
about the failure.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit f1b4021b)

Commit ba226d33 tried to fix crash of
the daemon when a domain with an open console was destroyed. The fix was
wrong as it tried to remove the callback also when the stream was
aborted, where at that point the fd stream driver was already freed and
removed.

This patch clears the callbacks with a helper right before the hash is
freed, so that it doesn't interfere with other codepaths where the
stream object is freed.

(cherry picked from commit 45edefc7)

When a domain has a active console connection and is destroyed the
callback is called on private data that no longer exist causing a
segfault.

(cherry picked from commit ba226d33)

Commit-id 'afc4631b' added the regfree(reg) to free resources alloc'd
during regcomp; however, reg still needed to be VIR_FREE()'d. The call
to regfree() also didn't account for possible NULL value.  Reformatted
the call to be closer to usage.
(cherry picked from commit 71da3b66)

Backported to 0.9.12 with afc4631b and its revert skipped.

Signed-off-by: Luca Tettamanti <ltettamanti acunu com>