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)

Missing modules is a common expected scenario for most libvirt usage on
RPM distributions like Fedora, so it doesn't really warrant logging at
WARN level. Use INFO instead

https://bugzilla.redhat.com/show_bug.cgi?id=1274849
(cherry picked from commit 9a0c7f5f)

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

We only wait 0.5 seconds for the session daemon to start up and present
its socket, which isn't sufficient for many users. Bump up the sleep
interval and retry amount so we wait for a total of 5.0 seconds.

(cherry picked from commit ca0c06f4)

Kernel/initrd files are essentially read-only shareable images and thus
should be handled in the same way. We already use the appropriate label
for kernel/initrd files when starting a domain, but when a domain gets
destroyed we would remove the labels which would make other running
domains using the same files very unhappy.

https://bugzilla.redhat.com/show_bug.cgi?id=921135Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 68acc701)

On every socket connect(2) attempt we were re-launching session
libvirtd, up to 100 times in 5 seconds.

This understandably caused some weird load races and intermittent
qemu:///session startup failures

https://bugzilla.redhat.com/show_bug.cgi?id=1271183
(cherry picked from commit 2eb7a975)

When we autolaunch libvirtd for session URIs, we spin in a retry
loop waiting for the daemon to start and the connect(2) to succeed.

However if we exceed the retry count, we don't explicitly raise an
error, which can yield a slew of different error messages elsewhere
in the code.

Explicitly raise the last connect(2) failure if we run out of retries.

(cherry picked from commit 8da02d52)

- Add some debugging
- Make the loop dependent only on retries
- Make it explicit that connect(2) success exits the loop
- Invert the error checking logic

(cherry picked from commit f102c714)

The auto-spawn code would originally attempt to spawn the
daemon for both ENOENT and ECONNREFUSED errors from connect().
The various refactorings eventually lost this so we only
spawn the daemon on ENOENT. The result is if the daemon exits
uncleanly, so that the socket is left in the filesystem, we
will never be able to auto-spawn the daemon again.

(cherry picked from commit 406ee8c2)

The generated output is dependent on perl hashtable ordering, which
gives different results for i686 and x86_64. Fix this by sorting
the hash keys before iterating over them

https://bugzilla.redhat.com/show_bug.cgi?id=1173641
(cherry picked from commit a1edb05c)

If dnsmasq specified DNSMASQ_IAID (so we're dealing with an IPv6
lease) but no DNSMASQ_MAC, we skip creation of the new lease object.

Also skip adding it to the leases array.

https://bugzilla.redhat.com/show_bug.cgi?id=1202350
(cherry picked from commit df9fe124)
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Allow <name> and <uuid> anywhere under <domain>, not just at the top:

error:XML document failed to validate against schema: Unable to validate
doc against /usr/share/libvirt/schemas/domain.rng
Expecting an element name, got nothing
Invalid sequence in interleave
Element domain failed to validate content

Introduced with the first RelaxNG schema in commit c642103f.

https://bugzilla.redhat.com/show_bug.cgi?id=1292131
(cherry picked from commit b4e0549f)
Signed-off-by: NJán Tomko <jtomko@redhat.com>

I'm hitting this little annoyance in fedora's package repo:

$ fedpkg prep
Downloading libvirt-1.2.20.tar.gz
...
+ /usr/bin/gzip -dc /home/crobinso/src/fedora/libvirt/libvirt-1.2.20.tar.gz
$ git clean -xdf
Removing libvirt-1.2.20.tar.gz
Skipping repository libvirt-1.2.20/

We git-ify the libvirt directory as part of applying patches in the spec
file, but 'git clean' will ignore subfolders that appear to be standalone
git repos.

Let's just delete the .git directory after we're done with it.

(cherry picked from commit 62ff210e)

Patch 51f9f03a introduces a regression
where if a blockCommit operation fails the disk is still marked as being
part of a block job but can't be unmarked later.

(cherry picked from commit ee744b5b)

While qemu may be prepared to do this libvirt is not. Forbid the block
ops until we fix our code.

(cherry picked from commit 51f9f03a)

Surprisingly we did not grab a VM job when a block job finished and we'd
happily rewrite the backing chain data. This made it possible to crash
libvirt when queueing two backing chains tightly and other badness.

To fix it, add yet another handler to the helper thread that handles
monitor events that require a job.

(cherry picked from commit 1a92c719)

(cherry picked from commit 5c634730)

As of fedora polkit-0.113-2, polkit-devel only pulls in polkit-libs, not
full polkit, but we need the latter for pkcheck otherwise our configure
test fails.

(cherry picked from commit 6600f4f3)

As of commit 69929941, we set graphics/@listen attribute according to the
first listen child element even if that element is of type='network'.
This was done for backward compatibility with applications which only
support the original listen attribute. However, by doing so we broke
migration to older libvirt which tried to check that the listen
attribute matches one of the listen child elements but which did not
take type='network' elements into account.

We are not concerned about compatibility with old applications when
formatting domain XML for migration for two reasons. The XML is consumed
only by libvirtd and the IP address associated with type='network'
listen address on the source host is just useless on the destination
host. Thus, we can safely avoid propagating the type='network' IP
address to graphics/@listen attribute when creating migratable XML.

https://bugzilla.redhat.com/show_bug.cgi?id=1265111Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit c0806dc3)

Commit 8125113c added code that should remove the disk backend if the
fronted hotplug failed for any reason. The code had a bug though as it
used the disk string for unplug rather than the backend alias. Fix the
code by pre-creating an alias string and using it instead of the disk
string. In cases where qemu does not support QEMU_CAPS_DEVICE, we ignore
the unplug of the backend since we can't really create an alias in that
case.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1262399
(cherry picked from commit 64c6695f)

This patch addresses BZ 1244895.

Adapt the sysfs TPM command cancel path for the TPM driver that
does not use a miscdevice anymore since Linux 4.0. Support old
and new paths and check their availability.

Add a mockup for the test cases to avoid the testing for
availability of the cancel path.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
(cherry picked from commit 5ed7afa9)

Since we can't know at service start how many VMs will be running we
can't calculate an apropriate shutdown timeout. So instead of killing
off the service just let it use it's own internal timeout mechanism.

References:
    http://bugs.debian.org/803714
    https://bugzilla.redhat.com/show_bug.cgi?id=1195544

(cherry picked from commit ba08d16d)

Machine name escaping follows the same rules as serice name escape,
except that '.' and '-' must not be escaped in machine names, due
to a bug in systemd-machined.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1282846Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 0e0149ce)

According to the documentation, CreateMachine accepts only 7bit ASCII
characters in the machinename parameter, so let's make sure we can start
machines with unicode names with systemd.  We already have a function
for that, we just forgot to use it.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1062943
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1282846Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit e24eda48)

The scope name, even according to our docs is
"machine-$DRIVER\x2d$VMNAME.scope" virSystemdMakeScopeName would use the
resource partition name instead of "machine-" if it was specified thus
creating invalid scope paths.

This makes libvirt drop cgroups for a VM that uses custom resource
partition upon reconnecting since the detected scope name would not
match the expected name generated by virSystemdMakeScopeName.

The error is exposed by the following log entry:

debug : virCgroupValidateMachineGroup:302 : Name 'machine-qemu\x2dtestvm.scope' for controller 'cpu' does not match 'testvm', 'testvm.libvirt-qemu' or 'machine-test-qemu\x2dtestvm.scope'

for a "/machine/test" resource and "testvm" vm.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1238570
(cherry picked from commit 88f6c007)

The libvirt file system storage driver determines what file to
act on by concatenating the pool location with the volume name.
If a user is able to pick names like "../../../etc/passwd", then
they can escape the bounds of the pool.  For that matter,
virStoragePoolListVolumes() doesn't descend into subdirectories,
so a user really shouldn't use a name with a slash.

Normally, only privileged users can coerce libvirt into creating
or opening existing files using the virStorageVol APIs; and such
users already have full privilege to create any domain XML (so it
is not an escalation of privilege).  But in the case of
fine-grained ACLs, it is feasible that a user can be granted
storage_vol:create but not domain:write, and it violates
assumptions if such a user can abuse libvirt to access files
outside of the storage pool.

Therefore, prevent all use of volume names that contain "/",
whether or not such a name is actually attempting to escape the
pool.

This changes things from:

$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
Vol ../../../../../../etc/haha created
$ rm /etc/haha

to:

$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
error: Failed to create vol ../../../../../../etc/haha
error: Requested operation is not valid: volume name '../../../../../../etc/haha' cannot contain '/'
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 034e47c3)

Well, in 8ad126e6 we tried to fix a memory corruption problem.
However, the fix was not as good as it could be. I mean, the
commit has one line more than it should. I've noticed this output
just recently:

  # ./run valgrind --leak-check=full --show-reachable=yes ./tools/virsh domblklist gentoo
  ==17019== Memcheck, a memory error detector
  ==17019== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==17019== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
  ==17019== Command: /home/zippy/work/libvirt/libvirt.git/tools/.libs/virsh domblklist gentoo
  ==17019==
  Target     Source
  ------------------------------------------------
  fda        /var/lib/libvirt/images/fd.img
  vda        /var/lib/libvirt/images/gentoo.qcow2
  hdc        /home/zippy/tmp/install-amd64-minimal-20150402.iso

  ==17019== Thread 2:
  ==17019== Invalid read of size 4
  ==17019==    at 0x4EFF5B4: virObjectUnref (virobject.c:258)
  ==17019==    by 0x5038CFF: remoteClientCloseFunc (remote_driver.c:552)
  ==17019==    by 0x5069D57: virNetClientCloseLocked (virnetclient.c:685)
  ==17019==    by 0x506C848: virNetClientIncomingEvent (virnetclient.c:1852)
  ==17019==    by 0x5082136: virNetSocketEventHandle (virnetsocket.c:1913)
  ==17019==    by 0x4ECD64E: virEventPollDispatchHandles (vireventpoll.c:509)
  ==17019==    by 0x4ECDE02: virEventPollRunOnce (vireventpoll.c:658)
  ==17019==    by 0x4ECBF00: virEventRunDefaultImpl (virevent.c:308)
  ==17019==    by 0x130386: vshEventLoop (vsh.c:1864)
  ==17019==    by 0x4F1EB07: virThreadHelper (virthread.c:206)
  ==17019==    by 0xA8462D3: start_thread (in /lib64/libpthread-2.20.so)
  ==17019==    by 0xAB441FC: clone (in /lib64/libc-2.20.so)
  ==17019==  Address 0x139023f4 is 4 bytes inside a block of size 240 free'd
  ==17019==    at 0x4C2B1F0: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==17019==    by 0x4EA8949: virFree (viralloc.c:582)
  ==17019==    by 0x4EFF6D0: virObjectUnref (virobject.c:273)
  ==17019==    by 0x4FE74D6: virConnectClose (libvirt.c:1390)
  ==17019==    by 0x13342A: virshDeinit (virsh.c:406)
  ==17019==    by 0x134A37: main (virsh.c:950)

The problem is, when registering remoteClientCloseFunc(), it's
conn->closeCallback which is ref'd. But in the function itself
it's conn->closeCallback->conn what is unref'd. This is causing
imbalance in reference counting. Moreover, there's no need for
the remote driver to increase/decrease conn refcount since it's
not used anywhere. It's just merely passed to client registered
callback. And for that purpose it's correctly ref'd in
virConnectRegisterCloseCallback() and then unref'd in
virConnectUnregisterCloseCallback().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit e6893007)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This reverts commit 1ce7c1d2,
which introduced a significant semantic change to the
virDomainGetInfo() API. Additionally, the change was only
made to 2 of the 15 virt drivers.

Conflicts:
	src/qemu/qemu_driver.c
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
(cherry picked from commit 60acb38a)

So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:

  virsh # start --console test
  error: Reconnected to the hypervisor
  error: Failed to start domain test
  error: internal error: guest failed to start: unexpected exit status 125

So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:

static virCommandPtr
virLXCProcessBuildControllerCmd(virLXCDriverPtr driver,
                                ..
                                int logfd,
                                const char *pidfile)
{
    ...
    virCommandSetOutputFD(cmd, &logfd);
    virCommandSetErrorFD(cmd, &logfd);
    ...
}

Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.

In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.

The bug was introduced in e1de5521.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 302146b1)

Future kernels will mandate the use of nosuid+nodev+noexec
flags when mounting the /proc/sys filesystem. Unconditionally
add them now since they don't harm things regardless and could
mitigate future security attacks.

(cherry picked from commit 24710414)

There was a couple of problems with the style fixes applied to the original
patch:

1.) virFileReadAllQuiet comparison was incorrectly parenthesized when moved
into a condition, causing the len to be set to the result of comparison. This,
together with the removed underflow check would underflow the phy buffer.

2.) The logic was broken. Failure to call "ip" would abort the function, thus
the "iw" branch would never be reached.

This aims to fix the issues and work around possible style complains :)
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
(cherry picked from commit 81b19ce4)

It's not a problem at all and causes virt-manager to break down.

Note: netcf 0.2.8 and earlier generates invalid XML for a bond with no
interfaces anyway, so in that case this error in libvirt is never
reached since we fail earlier.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
(cherry picked from commit efc68de5)

Upping an interface for no reason and not configuring it is a cardinal sin.

With the default addrgenmode if eui64 it sticks a link-local address to the
interface. That is not good, as NetworkManager would see an address configured,
assume the interface is already configured and won't touch it iself and the
interface might stay unconfigured until the end of the days.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1124721Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit c3cf3c43)

In one of my previous commits (49ed6cff) I've introduced a test
among with some files stored under virnetdevtestdata folder.
While this works perfectly within a git tree, the folder was not
getting into .tar.gz and therefore the dist-check would fail.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 598f3fdd)

The 802.11 interfaces can not be moved by themselves, their Phy has to move too.

If there are other interfaces, they have to move too -- hopefully it's not too
confusing. This is a less-invasive alternative to defining a new hostdev type
for PHYs.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 3a495948)

Throughout the code, we have several places need to construct a path
somewhere in /sys/class/net/... They are not consistent and nearly
each code piece invents its own way how to do it. So unify this by:

1) use virNetDevSysfsFile() wherever possible

2) At least use common macro SYSFS_NET_DIR declared in virnetdev.h at
   the rest of places which can't go with 1)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 96a21e97)

This is yet another test for check of basic functionality of our
NIC state handling code.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 49ed6cff)

Commit 49ed6cff is broken on mingw and other non-linux platforms:

  CCLD     libvirt.la
  Cannot export virNetDevSysfsFile: symbol not defined
  collect2: error: ld returned 1 exit status

* src/util/virnetdev.c: Provide virNetDevSysfsFile fallback.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 58dfc534)

==26726==    by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80)
==26726==    by 0x5673605: UnknownInlinedFun (stdio2.h:210)
==26726==    by 0x5673605: virVasprintfInternal (virstring.c:476)
==26726==    by 0x56736EE: virAsprintfInternal (virstring.c:497)
==26726==    by 0x5680C37: virGetUserRuntimeDirectory (virutil.c:866)
==26726==    by 0x5783A89: virNetSocketNewConnectUNIX (virnetsocket.c:572)
==26726==    by 0x57751AF: virNetClientNewUNIX (virnetclient.c:344)
==26726==    by 0x57689B3: doRemoteOpen (remote_driver.c:895)
==26726==    by 0x5769F8E: remoteConnectOpen (remote_driver.c:1195)
==26726==    by 0x57092DF: do_open (libvirt.c:1189)
==26726==    by 0x570A7BF: virConnectOpenAuth (libvirt.c:1341)

https://bugzilla.redhat.com/show_bug.cgi?id=1215042Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit da4d7c30)