This should resolve:

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

The problem was that qemuUpdateActivePciHostdevs was returning 0
(success) when no hostdevs were present, but would otherwise return -1
(failure) even when it completed successfully. It is only called from
qemuProcessReconnect(), and when qemuProcessReconnect got back an
error, it would not only stop reconnecting, but would terminate the
guest qemu process "to remove danger of it ending up running twice if
user tries to start it again later".

(This bug was introduced in commit 011cf7ad, which was pushed between
v1.0.2 and v1.0.3, so all maintenance branches from v1.0.3 up to 1.0.5
will need this one line patch applied.)
(cherry picked from commit 2ea45647)

CVE-2013-1962

remoteDispatchStoragePoolListAllVolumes wasn't freeing the pool.
The pool also held a reference to the connection, preventing it from
getting freed and closing the netcf interface driver, which held two
sockets open.
(cherry picked from commit ca697e90)

The controller element supports non-disk controller types too.

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

(cherry picked from commit 413274f6)

Set spice password even if default VNC password hasn't been set.

https://bugzilla.redhat.com/show_bug.cgi?id=953720
(cherry picked from commit 4327df7e)

If the path part of connection URI is not present, cfg is used
unitialized.

https://bugzilla.redhat.com/show_bug.cgi?id=950855
(cherry picked from commit 74bff250)

Upstream gnulib determined that we were needlessly compiling in
gnulib's regex instead of glibc's when targetting new-enough glibc,
because the m4 test was being too strict in requiring a particular
answer to undefined behavior.
https://lists.gnu.org/archive/html/bug-gnulib/2013-04/msg00032.html

* .gnulib: Update to latest, for regex.
(cherry picked from commit 84243239)

Cherry picked because I hit a failure of test-regex when swapping
between incremental builds of libvirt.git master then v1.0.4-maint.

While this update doesn't address any reported problems in libvirt,
doing a post-release update to latest gnulib makes it easier to
stay in sync with best upstream practices.

* .gnulib: Update to latest.
* bootstrap: Resynchronize.
(cherry picked from commit d7468b7d)

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

Commit d04916fa introduced a regression in audit quality - even
though the code was computing the proper escaped name for a
path, it wasn't feeding that escaped name on to the audit message.
As a result, /var/log/audit/audit.log would mention a pair of
fields class=path path=/dev/hpet instead of the intended
class=path path="/dev/hpet", which in turn caused ausearch to
format the audit log with path=(null).

* src/conf/domain_audit.c (virDomainAuditCgroupPath): Use
constructed encoding.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 31c6bf35)

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=949483Signed-off-by: NAlex Jia <ajia@redhat.com>
(cherry picked from commit c3e33e68)

Since commit b8a32e0e, all man pages
depend on configure.ac so that they are properly regenerated whenever
libvirt version changes. Thus libvirt.spec needs to have a build
dependency on pod2man when %{enable_autotools} is set.
(cherry picked from commit 6f1b9c8d)

By default, libtool builds two .o files for every .lo rule:
src/foo.o - static builds
src/.libs/foo.o - shared library builds

But since commit ad42b34b disabled static builds, src/foo.o is
no longer built by default.  On a fresh checkout, this means our
protocol check rules using pdwtags were testing a missing file,
and thanks to a lousy behavior of pdwtags happily giving no output
and 0 exit status (http://bugzilla.redhat.com/949034), we were
merely claiming that "dwarves is too old" and skipping the test.

However, if you swap between branches and do incremental builds,
such as building v0.10.2-maint and then switching back to master,
you end up with src/foo.o being leftover from its 0.10.2 state,
and then 'make check' fails because the .o file does not match
the protocol-structs file due to API additions in the meantime.

A simpler fix would be to always look in .libs for the .o to
be parsed; but since it is possible to pass ./configure options
to tell libtool to do a static-only build with no shared .o,
I went with the approach of finding the newest of the two files,
whenever both exist.

* src/Makefile.am (PDWTAGS): Ensure we test just-built file.
(cherry picked from commit 5899e09e)

The linker will ignore LD_PRELOAD libraries which do not
exist, just printing a warning message. This is not helpful
for the test suite which will be utterly fubar without the
preload library present. Add an explicit test for existence
of the library to protect against this
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit b1d3154a)

The last Viktor's effort to fix the race and memory corruption unfortunately
wasn't complete in the case the close callback was not registered in an
connection. At that time, the trail of event's that I'll describe later could
still happen and corrupt the memory or cause a crash of the client (including
the daemon in case of a p2p migration).

Consider the following prerequisities and trail of events:
Let's have a remote connection to a hypervisor that doesn't have a close
callback registered and the client is using the event loop. The crash happens in
cooperation of 2 threads. Thread E is the event loop and thread W is the worker
that does some stuff. R denotes the remote client.

1.) W - The client finishes everything and sheds the last reference on the client
2.) W - The virObject stuff invokes virConnectDispose that invokes doRemoteClose
3.) W - the remote close method invokes the REMOTE_PROC_CLOSE RPC method.
4.) W - The thread is preempted at this point.
5.) R - The remote side receives the close and closes the socket.
6.) E - poll() wakes up due to the closed socket and invokes the close callback
7.) E - The event loop is preempted right before remoteClientCloseFunc is called
8.) W - The worker now finishes, and frees the conn object.
9.) E - The remoteClientCloseFunc accesses the now-freed conn object in the
        attempt to retrieve pointer for the real close callback.
10.) Kaboom, corrupted memory/segfault.

This patch tries to fix this by introducing a new object that survives the
freeing of the connection object. We can't increase the reference count on the
connection object itself or the connection would never be closed, as the
connection is closed only when the reference count reaches zero.

The new object - virConnectCloseCallbackData - is a lockable object that keeps
the pointers to the real user registered callback and ensures that the
connection callback is either not called if the connection was already freed or
that the connection isn't freed while this is being called.
(cherry picked from commit 8ad126e6)

This patch improves the error message after disconnecting from the
hypervisor and adds the close callback operations required not to leak
the callback reference.
(cherry picked from commit 69ab0756)

The function is used to establish connection so it should be in the main
virsh file. This movement also enables further improvements done in next
patches.

Note that the "connect" command has moved from the host section of virsh to the
main section. It is now listed by 'virsh help virsh' instead of 'virsh help
host'.
(cherry picked from commit ca9e73eb)

Before closing the connection we unregister the close callback
to prevent a reference leak.

Further, the messages on virConnectClose != 0 are a bit more specific
now.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
(cherry picked from commit e964ba27)

By adjusting the reference count of the connection object we
prevent races between callback function and virConnectClose.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
(cherry picked from commit 03a43efa)

When creating a logical volume with virStorageVolCreateXMLFrom,
"qemu-img convert" is called internally if clonevol is a file volume.
Then, vol->target.format is used as output_fmt parameter but the
target.format of logical volumes is always 0 because logical volumes
haven't the volume format type element.

Fortunately, 0 was treated as RAW file format before commit f772b3d9,
so there was no problem. But now, 0 is treated as the type of none,
qemu-img fails with "Unknown file format 'none'".

This patch fixes this issue by treating output block devices as RAW
file format like for input block devices.
Signed-off-by: NAtsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
(cherry picked from commit d369e508)

By passing the flags -z relro -z now to the linker, we can force
it to resolve all library symbols at startup, instead of on-demand.
This allows it to then make the global offset table (GOT) read-only,
which makes some security attacks harder.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit fc8c1787)

PIE (position independent executable) adds security to executables
by composing them entirely of position-independent code (PIC. The
.so libraries already build with -fPIC. This adds -fPIE which is
the equivalent to -fPIC, but for executables. This for allows Exec
Shield to use address space layout randomization to prevent attackers
from knowing where existing executable code is during a security
attack using exploits that rely on knowing the offset of the
executable code in the binary, such as return-to-libc attacks.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1150999c)

Mimic the fix done in 02b90972 to fix crash by
accessing an already freed structure. Also copy the explaining comment why the
pointer can't be accessed any more.
(cherry picked from commit 43b6f304)

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

The virsh domfstrim command was not freeing allocated domain,
leaving leaked references behind.
(cherry picked from commit deb86ee9)

Reported by Anthony Messina in
https://bugzilla.redhat.com/show_bug.cgi?id=904692
Present since introduction of smartcard support in commit f5fd9baa

* src/qemu/qemu_command.c (qemuBuildCommandLine): Match qemu spelling.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args:
Fix broken test.
(cherry picked from commit 6f7e4ea3)

Code added by commit id '523207fe'

TEST: qemuxml2argvtest
      ........................................ 40
      ........................................ 80
      ........................................ 120
      ........................................ 160
      ........................................ 200
      ........................................ 240
      .................................        273 OK
==30993== 39 bytes in 1 blocks are definitely lost in loss record 33 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x41E501: fakeSecretGetValue (qemuxml2argvtest.c:33)
==30993==    by 0x427591: qemuBuildDriveURIString (qemu_command.c:2571)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 46 bytes in 1 blocks are definitely lost in loss record 64 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x38D690A167: __vasprintf_chk (in /usr/lib64/libc-2.16.so)
==30993==    by 0x4CB28E7: virVasprintf (stdio2.h:210)
==30993==    by 0x4CB29A3: virAsprintf (virutil.c:2017)
==30993==    by 0x4275B4: qemuBuildDriveURIString (qemu_command.c:2580)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 385 (56 direct, 329 indirect) bytes in 1 blocks are definitely los
==30993==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==30993==    by 0x4C6B2CF: virAllocN (viralloc.c:152)
==30993==    by 0x4C9C7EB: virObjectNew (virobject.c:191)
==30993==    by 0x4D21810: virGetSecret (datatypes.c:642)
==30993==    by 0x41E5D5: fakeSecretLookupByUsage (qemuxml2argvtest.c:51)
==30993==    by 0x4D4BEC5: virSecretLookupByUsage (libvirt.c:15295)
==30993==    by 0x4276A9: qemuBuildDriveURIString (qemu_command.c:2565)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==
PASS: qemuxml2argvtest

Interesting side note is that running the test singularly via 'make -C tests
check TESTS=qemuxml2argvtest' didn't trip the valgrind error; however,
running during 'make -C tests valgrind' did cause the error to be seen.
(cherry picked from commit 9a80050e)

Commit 9a3ff01d (which was ACKed at
the end of January, but for some reason didn't get pushed until during
the 1.0.4 freeze) fixed the logic in virPCIGetVirtualFunctions().
Unfortunately, a typo in the fix (replacing VIR_REALLOC_N with
VIR_ALLOC_N during code movement) caused not only a memory leak, but
also resulted in most of the elements of the result array being
replaced with NULL. virNetDevGetVirtualFunctions() assumed (and I think
rightly so) that virPCIGetVirtualFunctions() wouldn't return any NULL
elements in the array, so it ended up segfaulting.

This was found when attempting to use a virtual network with an
auto-created pool of SRIOV VFs, e.g.:

    <forward mode='hostdev' managed='yes'>
      <pf dev='eth4'/>
    </forward>

(the pool of PCI addresses is discovered by calling
virNetDevGetVirtualFunctions() on the PF dev).

- configure.ac docs/news.html.in libvirt.spec.in: updates for the release
- po/*.po*: fetch translation updates from Transifex and regenerate

Since the refactoring in fbe2d494 we call virSecretFree even if
virSecretDefineXML fails, which leads to overwriting the error
message with:
error: Invalid secret: virSecretFree

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

When logical pool has no PVs associated with itself (user-created),
virCommandFree(cmd) is called twice with the same pointer and that
causes a segfault in daemon.

Both virIsCapableFCHost and virIsCapableVport return 0 when the
respective sysfs path is accessible.

With my previous patches, we unconditionally appended a seclabel,
even if it wasn't generated but found in array of defined seclabels.
This resulted in double free later when doing virDomainDefFree
and iterating over the array of defined seclabels.

Moreover, there was another possibility of double free, if the
seclabel was generated in the last iteration of the process of
walking trough security managers array.

There has been a typo in virIsCapbleVport function name.

---
Pushed under build-breaker rule.

One of my previous patches manipulated virSecurityLabel* APIs,
some were added to header files, and some were renamed. However,
these changes were not reflected in libvirt_private.syms.

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

The <seclabel type='none'/> should be added iff there is no other
seclabel defined within a domain. This bug can be easily reproduced:
1) configure selinux seclabel for a domain
2) disable system's selinux and restart libvirtd
3) observe <seclabel type='none'/> being appended to a domain on its
   startup

The virDomainDefGetSecurityLabelDef was modifying the domain XML.
It tried to find a seclabel corresponding to given sec driver. If the
label wasn't found, the function created one which is wrong. In fact
it's security manager which should modify this part of domain XML.

When libvirtd loads active network configs from network state directory,
it should release the class_id memory block which was allocated
at the time of loading xml from network config directory.
virBitmapParse will create a new memory block of bitmap class_id which
causes a memory leak.

This happens when at least one virtual network is active before.

==12234== 8,216 (24 direct, 8,192 indirect) bytes in 1 blocks are definitely \
              lost in loss record 702 of 709
==12234==    at 0x4A06B2F: calloc (vg_replace_malloc.c:593)
==12234==    by 0x37AB04D77D: virAlloc (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB04EF89: virBitmapNew (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFB37: virNetworkAssignDef (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFD31: ??? (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFE92: virNetworkLoadAllConfigs (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x10650E5A: ??? (in /usr/lib64/libvirt/connection-driver/libvirt_driver_network.so)
==12234==    by 0x37AB0EB72F: virStateInitialize (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x40DE04: ??? (in /usr/sbin/libvirtd)
==12234==    by 0x37AB0832E8: ??? (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x3796807D14: start_thread (in /usr/lib64/libpthread-2.16.so)
==12234==    by 0x37960F246C: clone (in /usr/lib64/libc-2.16.so)