- 16 1月, 2014 3 次提交
-
-
由 Guido Günther 提交于
-
由 Jiri Denemark 提交于
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)
-
由 Jiri Denemark 提交于
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
-
- 11 1月, 2014 8 次提交
-
-
由 Jiri Denemark 提交于
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)
-
由 Jiri Denemark 提交于
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)
-
由 Jiri Denemark 提交于
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)
-
由 Jiri Denemark 提交于
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)
-
由 Daniel P. Berrange 提交于
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)
-
由 Eric Blake 提交于
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)
-
由 Eric Blake 提交于
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)
-
由 Michal Privoznik 提交于
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)
-
- 18 10月, 2013 1 次提交
-
-
由 Zhou Yimin 提交于
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
-
- 04 10月, 2013 1 次提交
-
-
由 Eric Blake 提交于
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>
-
- 02 10月, 2013 1 次提交
-
-
由 Guido Günther 提交于
-
- 01 10月, 2013 1 次提交
-
-
由 Guido Günther 提交于
Since cbcb1983 we need viratomic.h in the distributed tarball as well. This fixes "make distcheck".
-
- 27 9月, 2013 1 次提交
-
-
由 Guido Günther 提交于
-
- 19 9月, 2013 14 次提交
-
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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.
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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)
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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)
-
由 Eric Blake 提交于
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)
-
由 Jiri Denemark 提交于
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
-
由 Eric Blake 提交于
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
-
由 Eric Blake 提交于
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)
-
- 12 9月, 2013 10 次提交
-
-
由 Daniel P. Berrange 提交于
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
-
由 Daniel P. Berrange 提交于
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)
-
由 Peter Krempa 提交于
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)
-
由 Peter Krempa 提交于
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)
-
由 Luca Tettamanti 提交于
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>
-
由 Jiri Denemark 提交于
Thanks to this new option we are now able to use modern CPU models (such as Westmere) defined in external configuration file. The qemu-1.1{,-device} data files for qemuhelptest are filled in with qemu-1.1-rc2 output for now. I will update those files with real qemu-1.1 output once it is released. (cherry picked from commit 63b42436)
-
由 Peter Krempa 提交于
This patch resolves CVE-2013-0170: https://bugzilla.redhat.com/show_bug.cgi?id=893450 When reading and dispatching of a message failed the message was freed but wasn't removed from the message queue. After that when the connection was about to be closed the pointer for the message was still present in the queue and it was passed to virNetMessageFree which tried to call the callback function from an uninitialized pointer. This patch removes the message from the queue before it's freed. * rpc/virnetserverclient.c: virNetServerClientDispatchRead: - avoid use after free of RPC messages (cherry picked from commit 46532e3e)
-
由 Peter Krempa 提交于
While unescaping the commands the commands passed through to the monitor function qemuMonitorUnescapeArg() initialized lenght of the input string to strlen()+1 which is fine for alloc but not for iteration of the string. This patch fixes the off-by-one error and drops the pointless check for a single trailing slash that is automaticaly handled by the default branch of switch. (cherry picked from commit 0f4660c8)
-
由 Jiri Denemark 提交于
This reverts commit b1e374a7, which was rather bad since I failed to consider all sides of the issue. The main things I didn't consider properly are: - a thread which sends a non-blocking call waits for the thread with the buck to process the call - the code doesn't expect non-blocking calls to remain in the queue unless they were already partially sent Thus, the reverted patch actually breaks more than what it fixes and clients (which may even be libvirtd during p2p migrations) will likely end up in a deadlock. (cherry picked from commit 63643f67)
-
由 Eric Blake 提交于
We were being lazy - virnetlink.c was getting uint32_t as a side-effect from glibc 2.14's <unistd.h>, but older glibc 2.11 does not provide uint32_t from <unistd.h>. In fact, POSIX states that <unistd.h> need only provide intptr_t, not all of <stdint.h>, so the bug really is ours. Reported by Jonathan Alescio. * src/util/virnetlink.h: Include <stdint.h>. (cherry picked from commit e8314e78)
-