- 24 6月, 2019 2 次提交
-
-
由 Ján Tomko 提交于
This API can be used to execute arbitrary emulators. Forbid it on read-only connections. Fixes: CVE-2019-10167 Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 8afa68ba) Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
The virDomainSaveImageGetXMLDesc API is taking a path parameter, which can point to any path on the system. This file will then be read and parsed by libvirtd running with root privileges. Forbid it on read-only connections. Fixes: CVE-2019-10161 Reported-by: NMatthias Gerstner <mgerstner@suse.de> Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> (cherry picked from commit aed6a032) Signed-off-by: NJán Tomko <jtomko@redhat.com> Conflicts: src/libvirt-domain.c src/remote/remote_protocol.x Upstream commit 12a51f37 which introduced the VIR_DOMAIN_SAVE_IMAGE_XML_SECURE alias for VIR_DOMAIN_XML_SECURE is not backported. Just skip the commit since we now disallow the whole API on read-only connections, regardless of the flag. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 04 10月, 2016 7 次提交
-
-
由 Pavel Hrdina 提交于
Fix the regex for excluding files for this syntax-rule. The rule "include/" will not work, because we are matching the whole line like this "^(...|include/|...)$ so we need to use "include/libvirt/libvirt.+". The second issue is that we are using only one '$' but there should be two of those at the end. The last small adjustment is to escape dots '.' so it match only dot. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit a94efa50)
-
由 Eric Blake 提交于
Yet again, selinux has been adding const-correctness; this change is ABI-compatible, but breaks API, which affects us when we try to override things in our testsuite: ../../tests/securityselinuxhelper.c:307:24: error: conflicting types for 'selabel_open' struct selabel_handle *selabel_open(unsigned int backend, ^~~~~~~~~~~~ In file included from ../../tests/securityselinuxhelper.c:32:0: /usr/include/selinux/label.h:73:24: note: previous declaration of 'selabel_open' was here The problem is a new 'const' prior to the second parameter. Fix it the same way we did in commit 292d3f2d: check for the new const at configure time. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 5ea3a690)
-
由 Pavel Hrdina 提交于
fdstream.c: In function 'virFDStreamWrite': fdstream.c:390:29: error: logical 'or' of equal expressions [-Werror=logical-op] if (errno == EAGAIN || errno == EWOULDBLOCK) { ^~ Fedora rawhide now uses gcc 6.0 and there is a bug with -Wlogical-op producing false warnings. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602 Use GCC pragma push/pop and ignore -Wlogical-op for GCC that supports push/pop pragma and also has this bug. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit d713a6b1)
-
由 Michal Privoznik 提交于
While trying to build with -Os couple of compile errors showed up. conf/domain_conf.c: In function 'virDomainChrRemove': conf/domain_conf.c:13666:24: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized] virDomainChrDefPtr ret, **arrPtr = NULL; ^ Compiler fails to see that @ret is used only if set in the loop, but whatever, there's no harm in initializing the variable. In vboxAttachDrivesNew and _vboxAttachDrivesOld compiler thinks that @rc may be used uninitialized. Well, not directly, but maybe after some optimization. Yet again, no harm in initializing a variable. In file included from ./util/virthread.h:26:0, from ./datatypes.h:28, from vbox/vbox_tmpl.c:43, from vbox/vbox_V3_1.c:37: vbox/vbox_tmpl.c: In function '_vboxAttachDrivesOld': ./util/virerror.h:181:5: error: 'rc' may be used uninitialized in this function [-Werror=maybe-uninitialized] virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \ ^ In file included from vbox/vbox_V3_1.c:37:0: vbox/vbox_tmpl.c:1041:14: note: 'rc' was declared here nsresult rc; ^ Yet again, one uninitialized variable: qemu/qemu_driver.c: In function 'qemuDomainBlockCommit': qemu/qemu_driver.c:17194:9: error: 'baseSource' may be used uninitialized in this function [-Werror=maybe-uninitialized] qemuDomainPrepareDiskChainElement(driver, vm, baseSource, ^ And another one: storage/storage_backend_logical.c: In function 'virStorageBackendLogicalMatchPoolSource.isra.2': storage/storage_backend_logical.c:618:33: error: 'thisSource' may be used uninitialized in this function [-Werror=maybe-uninitialized] thisSource->devices[j].path)) ^ Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit bde6e002)
-
由 Marc Hartmayer 提交于
Before the variable 'bits' was initialized with 0 (commit 3470cd86), the following bug was possible. A function call with an empty bitmap leads to undefined behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0 and 'sz == 1'. So the non global and non static variable 'bits' would have never been set. Consequently the check 'bits == 0' results in undefined behavior. This patch clarifies the current version of the function by handling the empty bitmap explicitly. Also, for an empty bitmap there is obviously no bit set so we can just return -1 (indicating no bit set) right away. The explicit check for 'bits == 0' after the loop is unnecessary because we only get to this point if no set bit was found. Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> (cherry picked from commit 7cd01a24)
-
由 Martin Kletzander 提交于
When building using -Og, gcc sees that some variables can be used uninitialized It can be debatable whether it is possible with our codeflow, but functions should be self-contained and initializations are always good. The return instead of goto is due to actualType being used in the cleanup. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit 3470cd86)
-
由 Martin Kletzander 提交于
If this reminds you of a commit message from around a year ago, it's 41c2aa72 and yes, we're dealing with "the same thing" again. Or f309db1f and it's similar. There is a logic in place that if there is no real need for memory-backend-file, qemuBuildMemoryBackendStr() returns 0. However that wasn't the case with hugepage backing. The reason for that was that we abused the 'pagesize' variable for storing that information, but we should rather have a separate one that specifies whether we really need the new object for hugepage backing. And that variable should be set only if this particular NUMA cell needs special treatment WRT hugepages. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit 4372a7845acbc6974f6027ef68e7dd3eeb47f425)
-
- 30 6月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
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)
-
- 03 2月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Since commit 71408079 we are generating socket path later than before -- when starting a domain. That makes one particular inconsistent state of a chardev, which was not possible before, currently valid. However, SELinux security driver forgot to guard the main restoring function by a check for NULL-paths. So make it no-op for NULL paths, as in the DAC driver. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1300532Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit 1794a010) Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 02 2月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
In my previous commit a70f3b1c I've tried to fix case when building from VPATH and a file wasn't being installed. However, my fix broke non-VPATH build. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 0d0e41a7) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 01 2月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
The libvirt-common.h is build time generated file from .in. Obviously, it's generated into builddir and not srcdir. Problem is, the list of header files to install, virinc_HEADERS contains only $(srcdir)/*.h and this misses libvirt-common.h. This problem is pretty obvious when doing a VPATH build. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit a70f3b1c) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 19 1月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
Since we pass dummy variables @fdout and @fdoutlen into virNetClientProgramCall() we make it alloc @fdout array (even though it's an array of 0 elements since vitlogd can hardly pass us some FDs at this stage). Nevertheless, it's an allocation not followed by free(): ==29385== 0 bytes in 60 blocks are definitely lost in loss record 2 of 1,009 ==29385== at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29385== by 0x54B99EF: virAllocN (viralloc.c:191) ==29385== by 0x56821B1: virNetClientProgramCall (virnetclientprogram.c:359) ==29385== by 0x563B304: virLogManagerDomainReadLogFile (log_manager.c:272) ==29385== by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485) ==29385== by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660) ==29385== by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696) ==29385== by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957) ==29385== by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955) ==29385== by 0x217F71A4: qemuProcessStart (qemu_process.c:5152) ==29385== by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396) ==29385== by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit c03fbecc) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So I can observe this crasher that with freshly started daemon (and virtlogd enabled) I am trying to startup a domain that immediately dies (because it's said to use huge pages but I haven't allocated a single one in the pool). Hardly reproducible with -O0 or under valgrind. But I just got lucky: ==20469== Invalid write of size 8 ==20469== at 0x4C2E99B: memcpy@GLIBC_2.2.5 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20469== by 0x217EDD07: qemuProcessReadLog (qemu_process.c:1670) ==20469== by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696) ==20469== by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957) ==20469== by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955) ==20469== by 0x217F71A4: qemuProcessStart (qemu_process.c:5152) ==20469== by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396) ==20469== by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450) ==20469== by 0x21846845: qemuDomainCreate (qemu_driver.c:7468) ==20469== by 0x5611CD0: virDomainCreate (libvirt-domain.c:6753) ==20469== by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613) ==20469== by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589) ==20469== Address 0x27a52ad0 is 0 bytes after a block of size 5,584 alloc'd ==20469== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20469== by 0x9B8D1DB: xdr_string (in /lib64/libc-2.21.so) ==20469== by 0x563B39C: xdr_virLogManagerProtocolNonNullString (log_protocol.c:24) ==20469== by 0x563B6B7: xdr_virLogManagerProtocolDomainReadLogFileRet (log_protocol.c:123) ==20469== by 0x164B34: virNetMessageDecodePayload (virnetmessage.c:407) ==20469== by 0x5682360: virNetClientProgramCall (virnetclientprogram.c:379) ==20469== by 0x563B30E: virLogManagerDomainReadLogFile (log_manager.c:272) ==20469== by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485) ==20469== by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660) ==20469== by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696) ==20469== by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957) ==20469== by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955) This points to memmove() in qemuProcessReadLog(). Imagine we just read the following string from qemu: "abc\n2016-01-18T09:40:44.022744Z qemu-system-x86_64: Error\n" After the first pass of the while() loop in the qemuProcessReadLog() (in which we have taken the false branch in the if) @buf still points to the beginning of the string, @filter_next points to the beginning of the second line. So we start second iteration because there is yet another newline character at the end. In this iteration @eol points to it actually. Now, the control gets inside true branch of if(). Just to remind you: got = 58 filter_next = buf + 5, eol = buf + 58. Therefore skip = 54 which is correct. The message we want to skip is 54 bytes long. However: memmove(filter_next, eol + 1, (got - skip) +1); which is memmove(filter_next, eol + 1, 5) is obviously wrong as there is only one byte we can access, not 5! Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 105b51f4) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 1月, 2016 1 次提交
-
-
由 Daniel Veillard 提交于
* docs/news.html.in libvirt.spec.in: update for release * po/*.po*: regenerated
-
- 15 1月, 2016 6 次提交
-
-
由 Jiri Denemark 提交于
A device tree binary file specified by /domain/os/dtb element is a read-only resource similar to kernel and initrd files. We shouldn't restore its label when destroying a domain to avoid breaking other domains configure with the same device tree. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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>
-
由 Yaniv Kaul 提交于
We have this function qemuAgentNotifyEvent() which is supposed to be called from thread pool responsible for processing qemu monitor events. The function then should wake up other thread that is waiting for a guest to shutdown or reboot. However, if we have received a different error a warning is printed out. This warning lacks info on which event is expected. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Commit id '90b721e4' moved where the virCgroupAddTask was made until after the check for the vcpupin checks. However, in doing so it missed an option where if the cpumap didn't exist, then the code would continue back to the top of the current vcpu loop. The results was that the virCgroupAddTask wouldn't be called. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
This reverts commit ae09988e. Since commit id '71ce4759' has been reverted, this one is no longer necessary.
-
由 John Ferlan 提交于
This reverts commit 71ce4759. Since commit id 'a41c00b4' has been reverted, this no longer is necessary
-
- 14 1月, 2016 5 次提交
-
-
由 John Ferlan 提交于
This reverts commit a41c00b4. After much testing and upstream discussion this has been deemed to be the incorrect operation since it means we no longer have any guarantee about which resource controllers the QEMU processes in general are in.
-
由 Cédric Bosdonnat 提交于
There is no need to deny writes on a readonly mount: write still won't be accepted, even if the user remounts the folder as RW in the guest as qemu sets the 9p mount as ro. This deny rule was leading to problems for example with readonly /: The qemu process had to write to a bunch of files in / like logs, sockets, etc. This deny rule was also preventing auditing of these denials, making it harder to debug.
-
由 John Ferlan 提交于
Commit id '7bf3198d' neglected to initialize deflate leading to a possibility if model allocation/checks fail, then the VIR_FREE(deflate) would be erroneous. Noted by Jan Tomko.
-
由 Michal Privoznik 提交于
In 50078cfb I've tried to fix distcheck but accidentally broke rpm build. The problem is that rpm build not only sets DESTDIR but also passes plugindir path. This results in double DESTDIR being in the plugin path, Drop one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Guido Günther 提交于
Mention that we run a command in that namespace
-
- 13 1月, 2016 8 次提交
-
-
由 Cole Robinson 提交于
Even though the Makefile has WITH_WIRESHARK guards, the _SOURCES variables are still processed when adding bits to the dist archive. plugin.c is a generated file that is only built when wireshark is enabled and it shouldn't be distributed, so use 'nodist'
-
由 Michal Privoznik 提交于
So, you try to start a domain, but before we even get to the part where chardev part of qemu command line is generated (and possibly missing path to unix sockets is made up) an error occurs which results in calling qemuProcessStop. This will then try to clean up the mess and possibly ends up calling unlink(NULL). ==8085== Thread 3: ==8085== Syscall param unlink(pathname) points to unaddressable byte(s) ==8085== at 0xA85EA57: unlink (in /lib64/libc-2.21.so) ==8085== by 0x213D3C24: qemuProcessCleanupChardevDevice (qemu_process.c:2866) ==8085== by 0x558D6B1: virDomainChrDefForeach (domain_conf.c:22924) ==8085== by 0x213DA9AE: qemuProcessStop (qemu_process.c:5326) ==8085== by 0x213DA2F2: qemuProcessStart (qemu_process.c:5190) ==8085== by 0x2142957F: qemuDomainObjStart (qemu_driver.c:7396) ==8085== by 0x214297DB: qemuDomainCreateWithFlags (qemu_driver.c:7450) ==8085== by 0x21429842: qemuDomainCreate (qemu_driver.c:7468) ==8085== by 0x5611B95: virDomainCreate (libvirt-domain.c:6753) ==8085== by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613) ==8085== by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589) ==8085== by 0x568BF41: virNetServerProgramDispatchCall (virnetserverprogram.c:437) ==8085== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==8085== Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jim Fehlig 提交于
Commit ec63000a missed checking the return value of regcomp(), which coverity promptly identified.
-
由 Michal Privoznik 提交于
Like everything we install, it should be prefixed with DESTDIR. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jim Fehlig 提交于
Commmit fd2e3c4c used the domctl version 8 structure for version 9 in the xen_getdomaininfolist union, resulting in insufficient buffer size (and subsequent memory corruption) for the GETDOMAININFOLIST ioctl. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Cole Robinson 提交于
- Don't double check for expectName - actual is always non-NULL by this point, so don't check it either
-
由 Cole Robinson 提交于
Just handle it all in tools/Makefile.am. I verified the generated output looks similar to the pre patch output, but I didn't test it.
-
由 Michal Privoznik 提交于
So after da176bf6 and friend we have switched to $(wildcard some/path/*.xml) instead of enumerating the files explicitly. This is nice, however it makes distcheck build from VPATH fail. The reason is that it's is not obvious to what does the wildcard refer to: srcdir or builddir? Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 1月, 2016 5 次提交
-
-
由 Dmitry Andreev 提交于
Autodeflate can be enabled/disabled for memballon device of model 'virtio'. xml: <devices> <memballoon model='virtio' autodeflate='on'/> </devices> qemu: qemu -device virtio-balloon-pci,...,deflate-on-oom=on Autodeflate cannot be enabled/disabled for running domain.
-
由 Dmitry Andreev 提交于
Add appropriate capability check and new virQEMUCaps flag for the new virtio balloon feature. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80
-
由 Dmitry Andreev 提交于
Excessive memory balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. QEMU memballoon device has a feature to release some memory at the last moment before some process will be get killed by OOM-killer. Introduce a new optional balloon device attribute 'autodeflate' to enable or disable this feature.
-
由 Cole Robinson 提交于
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
-
由 Cole Robinson 提交于
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.
-