be5d96d...
by
=?utf-8?q?J=C3=A1n_Tomko?= <email address hidden>
api: disallow virConnectGetDomainCapabilities on read-only connections
This API can be used to execute arbitrary emulators.
Forbid it on read-only connections.
Fixes: CVE-2019-10167
Signed-off-by: Ján Tomko <email address hidden>
Reviewed-by: Daniel P. Berrangé <email address hidden>
(cherry picked from commit 8afa68bac0cf99d1f8aaa6566685c43c22622f26)
Signed-off-by: Ján Tomko <email address hidden>
980109c...
by
=?utf-8?q?J=C3=A1n_Tomko?= <email address hidden>
api: disallow virDomainSaveImageGetXMLDesc on read-only connections
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: Matthias Gerstner <email address hidden>
Signed-off-by: Ján Tomko <email address hidden>
Reviewed-by: Daniel P. Berrangé <email address hidden>
(cherry picked from commit aed6a032cead4386472afb24b16196579e239580)
Signed-off-by: Ján Tomko <email address hidden>
Upstream commit 12a51f372 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.
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: Pavel Hrdina <email address hidden>
(cherry picked from commit a94efa50e253cb59a2925dca2705bce801f46fb1)
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: Eric Blake <email address hidden>
(cherry picked from commit 5ea3a690a28ed1d7ef1253a6e63e236541cceba2)
Use GCC pragma push/pop and ignore -Wlogical-op for GCC that supports
push/pop pragma and also has this bug.
Signed-off-by: Pavel Hrdina <email address hidden>
(cherry picked from commit d713a6b120904c488170e7920c482b2fade70ae1)
6a293aa...
by
Michal Privoznik <email address hidden>
Initialize couple of variables.
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: Michal Privoznik <email address hidden>
(cherry picked from commit bde6e002b52d110585a0d1618d25878ba177e927)
598845b...
by
Marc Hartmayer <email address hidden>
util: bitmap: clarify virBitmapLastSetBit() behavior for empty bitmaps
Before the variable 'bits' was initialized with 0 (commit
3470cd860d517760b13e26d97b6a842ff72687a1), 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: Boris Fiuczynski <email address hidden>
Reviewed-by: Sascha Silbe <email address hidden>
Reviewed-by: Bjoern Walk <email address hidden>
Signed-off-by: Marc Hartmayer <email address hidden>
(cherry picked from commit 7cd01a248b3995909adad29a6edbe76d3d16510f)
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: Martin Kletzander <email address hidden>
(cherry picked from commit 3470cd860d517760b13e26d97b6a842ff72687a1)
qemu: Only use memory-backend-file with NUMA if needed
If this reminds you of a commit message from around a year ago, it's
41c2aa729f0af084ede95ee9a06219a2dd5fb5df and yes, we're dealing with
"the same thing" again. Or f309db1f4d51009bad0d32e12efc75530b66836b 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.
Signed-off-by: Martin Kletzander <email address hidden>
(cherry picked from commit 4372a7845acbc6974f6027ef68e7dd3eeb47f425)
2d5370e...
by
Jiri Denemark <email address hidden>
qemu: Let empty default VNC password work as documented
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".
