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 2ea45647bc)
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 ca697e90d5)
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 842432390b)
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 d7468b7d47)
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: Eric Blake <eblake@redhat.com>
(cherry picked from commit 31c6bf35b9)
Since commit b8a32e0e94, 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 6f1b9c8d2a)
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 5899e09e61)
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: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit b1d3154a50)
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 8ad126e695)
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 69ab07560a)
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 ca9e73ebb6)
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: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
(cherry picked from commit e964ba2786)
By adjusting the reference count of the connection object we
prevent races between callback function and virConnectClose.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
(cherry picked from commit 03a43efa86)
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: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
(cherry picked from commit d369e50825)
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: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit fc8c1787d8)
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: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1150999ca4)
Mimic the fix done in 02b9097274 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 43b6f304bc)
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 6f7e4ea359)
Code added by commit id '523207fe8'
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 9a80050e52)
Commit 9a3ff01d7f (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).
Since the refactoring in fbe2d49 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.
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.
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)
iptables-1.4.18 removed the long deprecated "state" match.
Use "conntrack" instead in forwarding rules.
Fixes openSUSE bug https://bugzilla.novell.com/811251#811251.
Despite the comment stating virNetClientIncomingEvent handler should
never be called with either client->haveTheBuck or client->wantClose
set, there is a sequence of events that may lead to both booleans being
true when virNetClientIncomingEvent is called. However, when that
happens, we must not immediately close the socket as there are other
threads waiting for the buck and they would cause SIGSEGV once they are
woken up after the socket was closed. Another thing is we should clear
all remaining calls in the queue after closing the socket.
The situation that can lead to the crash involves three threads, one of
them running event loop and the other two calling libvirt APIs. The
event loop thread detects an event on client->sock and calls
virNetClientIncomingEvent handler. But before the handler gets a chance
to lock client, the other two threads (T1 and T2) start calling some
APIs. T1 gets the buck and detects EOF on client->sock while processing
its RPC call. Since T2 is waiting for its own call, T1 passes the buck
on to it and unlocks client. But before T2 gets the signal, the event
loop thread wakes up, does its job and closes client->sock. The crash
happens when T2 actually wakes up and tries to do its job using a closed
client->sock.
When we write a log message into a log, we separate thread ID from
timestamp using ": ". However, when storing the message into the ring
buffer, we omitted the separator, e.g.:
2013-02-27 11:49:11.852+00003745: ...
#virsh detach-device $guest usb.xml
error: Failed to detach device from usb2.xml
error: operation failed: host usb device vendor=0x0951 \
product=0x1625 not found
This regresstion is due to a typo in matching function. The first
argument is always the usb device that we are checking for. If the
usb xml file provided by user contains bus and device info, we try
to search it by them, otherwise, we use vendor and product info.
The bug occurred only when detaching a usb device with no bus and
device info provided in the usb xml file.
f946462e14 changed behavior by settings
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI upfront. If we do so before invoking
qemuDomainPCIAddressEnsureAddr we merely try to set the PCI slot via
qemuDomainPCIAddressReserveSlot instead reserving a new address via
qemuDomainPCIAddressSetNextAddr which fails with
$ ~/run-tck-test domain/200-disk-hotplug.t
./scripts/domain/200-disk-hotplug.t .. # Creating a new transient domain
./scripts/domain/200-disk-hotplug.t .. 1/5 # Attaching the new disk /var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img
# Failed test 'disk has been attached'
# at ./scripts/domain/200-disk-hotplug.t line 67.
# died: Sys::Virt::Error (libvirt error code: 1, message: internal error unable to reserve PCI address 0:0:0.0
# )
Since we switched from direct host migration scheme to the one,
where we connect to the destination and then just pass a FD to a
qemu, we have uncovered a qemu bug. Qemu expects migration FD to
block. However, we are passing a nonblocking one which results in
cryptic error messages like:
qemu: warning: error while loading state section id 2
load of migration failed
The bug is already known to Qemu folks, but we should workaround
already released Qemus. Patch has been originally proposed by Stefan
Hajnoczi <stefanha@gmail.com>
virConnectOpenAuth didn't require 'name' to be specified (VIR_DEBUG
used NULLSTR() for the output) and by default, if name == NULL, the
default connection uri is used. This was not indicated in the
documentation and wasn't checked for in other API's VIR_DEBUG outputs.
