Upstream is no longer willing to backport patches to a branch
this old. If you disagree with the policy, please volunteer
to become the branch maintainer on libvir-list@redhat.com
Signed-off-by: Eric Blake <eblake@redhat.com>
If the XML_PARSE_NOENT flag is passed to libxml2, then any
entities in the input document will be fully expanded. This
allows the user to read arbitrary files on the host machine
by creating an entity pointing to a local file. Removing
the XML_PARSE_NOENT flag means that any entities are left
unchanged by the parser, or expanded to "" by the XPath
APIs.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6b27d3e4c40946efa79e91d134616b41b1666c4)
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 46532e3e8ed5f5a736a02f67d6c805492f9ca720)
Conflicts:
src/rpc/virnetserverclient.c
When p2p migration fails early because qemuMigrationIsAllowed or
qemuMigrationIsSafe say migration should be cancelled, we fail to clear
the migration-out async job. As a result of that, further APIs called
for the same domain may fail with Timed out during operation: cannot
acquire state change lock.
Reported by Guido Winkelmann.
Conflicts:
src/qemu/qemu_migration.c - qemuMigrationIsSafe was not there in
0.9.6 yet
Fix for CVE-2012-4423.
When generating RPC protocol messages, it's strictly needed to have a
continuous line of numbers or RPC messages. However in case anyone
tries backporting some functionality and will skip a number, there is
a possibility to make the daemon segfault with newer virsh (version of
the library, rpc call, etc.) even unintentionally.
The problem is that the skipped numbers will get func filled with
NULLs, but there is no check whether these are set before the daemon
tries to run them. This patch very simply enhances one check and fixes
that.
(cherry picked from commit b7ff9e696063189a715802d081d55a398663c15a)
Fix for CVE-2012-4423.
When generating RPC protocol messages, it's strictly needed to have a
continuous line of numbers or RPC messages. However in case anyone
tries backporting some functionality and will skip a number, there is
a possibility to make the daemon segfault with newer virsh (version of
the library, rpc call, etc.) even unintentionally.
The problem is that the skipped numbers will get func filled with
NULLs, but there is no check whether these are set before the daemon
tries to run them. This patch very simply enhances one check and fixes
that.
(cherry picked from commit b7ff9e696063189a715802d081d55a398663c15a)
Using automake.git (will become 1.12 someday), I got this error:
configure.ac:90: error: automatic de-ANSI-fication support has been removed
/usr/local/share/aclocal-1.11a/protos.m4:13: AM_C_PROTOTYPES is expanded from...
configure.ac:90: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
In short, pre-C89 compilers are no longer a viable portability
target. Besides, our code base already requires C99, so worrying
about pre-C89 seems pointless.
* configure.ac (AM_C_PROTOTYPES): Drop, since newer automake no
longer provides it.
(cherry picked from commit 307f3635093b0e89ff78d544d1f81a7c0f589e51)
Commit a56c347 introduced a use of random numbers into seclabel
handling, but failed to initialize the random number generator
in the testsuite. Also, fail with usual status, not 255.
* tests/seclabeltest.c (main): Initialize randomness.
(cherry picked from commit a22a36e8feaef19413e1a6af533eaa50f3c5df2d)
Conflicts:
tests/seclabeltest.c
This bug resolves https://bugzilla.redhat.com/show_bug.cgi?id=810100
rpm builds for i686 were failing with a segfault in
networkxml2argvtest. Running under valgrind showed that a region of
memory was being referenced after it had been freed (as the result of
realloc - see the valgrind report in the BZ).
The problem (in replaceTokens() - added in commit 22ec60, meaning this
bug was in 0.9.10 and 0.9.11) was that the pointers token_start and
token_end were being computed based on the value of *buf, then *buf
was being realloc'ed (potentially moving it), then token_start and
token_end were used without recomputing them to account for movement
of *buf.
The solution is to change the code so that token_start and token_end
are offsets into *buf rather than pointers. This way there is only a
single pointer to the buffer, and nothing needs readjusting after a
realloc. (You may note that some uses of token_start/token_end didn't
need to be changed to add in "*buf +" - that's because there ended up
being a +*buf and -*buf which canceled each other out).
DV gets the credit for finding this bug and pointing out the valgrind
report.
(cherry picked from commit bde32b1ada0d0c8d9e3f82bebe19472b620ef54e)
The path to the dnsmasq binary can be configured while in the test data
the path is hard-coded to /usr/bin/. This break the test suite if a the
binary is located in a different location, like /usr/local/sbin/.
Replace the hard coded path in the test data by a token, which is
dynamically replaced in networkxml2argvtest with the configured path
after the test data has been loaded.
(Another option would have been to modify configure.ac to generate the
test data during configure, but I do not know of an easy way do trick
configure into mass-generate those test files without listing every
single one, which I consider less flexible.)
- unit-test the unit-test:
#include <assert.h>
#define TEST(in,token,rep,out) { char *buf = strdup(in); assert(!replaceTokens(&buf, token, rep) && !strcmp(buf, out)); free(buf); }
TEST("", "AA", "B", "");
TEST("A", "AA", "B", "A");
TEST("AA", "AA", "B", "B");
TEST("AAA", "AA", "B", "BA");
TEST("AA", "AA", "BB", "BB");
TEST("AA", "AA", "BBB", "BBB");
TEST("<AA", "AA", "B", "<B");
TEST("<AA", "AA", "BB", "<BB");
TEST("<AA", "AA", "BBB", "<BBB");
TEST("AA>", "AA", "B", "B>");
TEST("AA>", "AA", "BB", "BB>");
TEST("AA>", "AA", "BBB", "BBB>");
TEST("<AA>", "AA", "B", "<B>");
TEST("<AA>", "AA", "BB", "<BB>");
TEST("<AA>", "AA", "BBB", "<BBB>");
TEST("<AA|AA>", "AA", "B", "<B|B>");
TEST("<AA|AA>", "AA", "BB", "<BB|BB>");
TEST("<AA|AA>", "AA", "BBB", "<BBB|BBB>");
TEST("<AAAA>", "AA", "B", "<BB>");
TEST("<AAAA>", "AA", "BB", "<BBBB>");
TEST("<AAAA>", "AA", "BBB", "<BBBBBB>");
TEST("AAAA>", "AA", "B", "BB>");
TEST("AAAA>", "AA", "BB", "BBBB>");
TEST("AAAA>", "AA", "BBB", "BBBBBB>");
TEST("<AAAA", "AA", "B", "<BB");
TEST("<AAAA", "AA", "BB", "<BBBB");
TEST("<AAAA", "AA", "BBB", "<BBBBBB");
alarm(1); /* no infinite loop */
TEST("A", "A", "A", "A");
TEST("AA", "A", "A", "AA");
alarm(0);
Signed-off-by: Philipp Hahn <hahn@univention.de>
(cherry picked from commit 22ec60001e9a41fbd529922551313970224aad94)
Conflicts:
tests/networkxml2argvdata/nat-network-dns-srv-record-minimal.argv
tests/networkxml2argvdata/nat-network-dns-srv-record.argv
Daemon uses the following pattern when dispatching APIs with typed
parameters:
VIR_ALLOC_N(params, nparams);
virDomain*(dom, params, &nparams, flags);
virTypedParameterArrayClear(params, nparams);
In case nparams was originally set to 0, virDomain* API would fill it
with the number of typed parameters it can provide and we would use this
number (rather than zero) to clear params. Because VIR_ALLOC* returns
non-NULL pointer even if size is 0, the code would end up walking
through random memory. If we were lucky enough and the memory contained
7 (VIR_TYPED_PARAM_STRING) at the right place, we would try to free a
random pointer and crash.
Let's make sure params stays NULL when nparams is 0.
(cherry picked from commit 6039a2cb49c8af4c68460d2faf365a7e1c686c7b)
Conflicts:
daemon/remote.c - context differences, and fewer call sites
Pick up some build fixes in the latest gnulib. In particular,
we want to ensure that official tarballs are secure, but don't
want to penalize people who don't run 'make dist', since fixed
automake still hasn't hit common platforms like Fedora 17.
* .gnulib: Update to latest, for Automake CVE-2012-3386 detection.
* bootstrap: Resync from gnulib.
* bootstrap.conf (gnulib_extra_files): Drop missing, since gnulib
has dropped it in favor of Automake's version.
* cfg.mk (local-checks-to-skip): Conditionally skip the security
check in cases where it doesn't matter.
(cherry picked from commit f12e1396212b9127306245c61566f171a3df7aa3)
Conflicts:
.gnulib - skip all intermediate commits touching this file
bootstrap - likewise
Gnulib finally relaxed the isatty license, needed as first mentioned here:
https://www.redhat.com/archives/libvir-list/2012-February/msg01022.html
Other improvements include better syntax-check rules (we can delete one
of ours now that it is a duplicate) and better compiler warning usage.
* .gnulib: Update to latest, for isatty.
* cfg.mk (sc_prohibit_strncpy): Drop a now-redundant rule.
* bootstrap.conf (gnulib_modules): Add isatty.
* bootstrap: Resync from gnulib.
(cherry picked from commit e925ea3156f2cc8d57a29eeeb839202adc989391)
Conflicts:
.gnulib - skip all intermediate commits touching this file
bootstrap - likewise
If we migrate to fd, spec->fwdType is not MIGRATION_FWD_DIRECT,
we will close spec->dest.fd.local in qemuMigrationRun(). So we
should set spec->dest.fd.local to -1 in qemuMigrationRun().
Bug present since 0.9.5 (commit 326176179).
(cherry picked from commit b19c236d69278c967d2d8b4aae97ac76213f1c10)
We should not set *outfd or *errfd if virExecWithHook() failed
because the caller may close these fds.
Bug present since v0.4.5 (commit 60ed1d2a).
(cherry picked from commit 746ff701e8727439cac8ca72531d82e5cb7fa129)
Wen Congyang reported that we have a double-close bug if we fail
virFDStreamOpenInternal, since childfd duplicated one of the fds[]
array contents. In truth, since we always transfer both members
of fds to other variables, we should close the fds through those
other names, and just use fds[] for pipe().
Bug present since 0.9.0 (commit e886237a).
* src/fdstream.c (virFDStreamOpenFileInternal): Swap scope of
childfd and fds[], to avoid a double close.
(cherry picked from commit f3cfc7c8848006b613e09bb1acd081716854527e)
KAMEZAWA Hiroyuki reported a nasty double-free bug when virCommand
is used to convert a string into input to a child command. The
problem is that the poll() loop of virCommandProcessIO would close()
the write end of the pipe in order to let the child see EOF, then
the caller virCommandRun() would also close the same fd number, with
the second close possibly nuking an fd opened by some other thread
in the meantime. This in turn can have all sorts of bad effects.
The bug has been present since the introduction of virCommand in
commit f16ad06f.
This is based on his first attempt at a patch, at
https://bugzilla.redhat.com/show_bug.cgi?id=823716
* src/util/command.c (_virCommand): Drop inpipe member.
(virCommandProcessIO): Add argument, to avoid closing caller's fd
without informing caller.
(virCommandRun, virCommandNewArgs): Adjust clients.
(cherry picked from commit da831afcf2f6c0d3ed1ea3128a6208f548a05d8f)
Conflicts:
src/util/command.c
virCommandRunAsync() will set errfd if it succeed. We should
close it if virFDStreamOpenInternal() fails.
(cherry picked from commit 655cffa0f25be40c68624036af80bde102177612)
If the system does not support bypass cache, we will close fd,
but it is uninitialized.
(cherry picked from commit 0a045f01cfa48fabd41c801e3f44034a4e6da485)
The uhci1, uhci2, uhci3 companion controllers for ehci1 must
have a master start port set. Since this value is predictable
we should set it automatically if the app does not supply it
(cherry picked from commit 03b804a200e214e3faf264b16f41a640c1344962)
Currently each USB2 companion controller gets put on a separate
PCI slot. Not only is this wasteful of PCI slots, but it is not
in compliance with the spec for USB2 controllers. The master
echi1 and all companion controllers should be in the same slot,
with echi1 in function 7, and uhci1-3 in functions 0-2 respectively.
* src/qemu/qemu_command.c: Special case handling of USB2 controllers
to apply correct pci slot assignment
* tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.args,
tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.xml: Expand
test to cover automatic slot assignment
(cherry picked from commit 1ebd52cb871f87b7868503b28448e96d59e41d63)
Conflicts:
tests/qemuxml2xmltest.c
The virDomainDeviceInfoIsSet API was only checking if an
address or alias was set in the struct. Thus if only a
rom bar setting / filename, boot index, or USB master
value was set, they could be accidentally dropped when
formatting XML
(cherry picked from commit 2c195fdbf3293792e39bc4f06755ae751025b0ea)
Conflicts:
src/conf/domain_conf.c
(crobinso: some elements aren't in maint branch, drop them)
The glibc ones (intentionally) cannot handle ptys opened in a
devpts not mounted at /dev/pts.
Drop the (un-exported, unused) virFileOpenTtyAt.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 80710c69fee323870b2a8239d93c5e5dddf28366)
Conflicts:
src/lxc/lxc_controller.c
When using the xm/xend stack to manage instances there is a bug
that causes the emulated interfaces to be unusable when the vif
config contains type=ioemu.
The current code already has a special quirk to not use this
keyword if no specific model is given for the emulated NIC
(defaulting to rtl8139).
Essentially it works because regardless of the type argument,i
the Xen stack always creates emulated and paravirt interfaces and
lets the guest decide which one to use. So neither xl nor xm stack
actually require the type keyword for emulated NICs.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 10c31135f321851f02ad1985684389a42f6f5e54)
On newer xend (v3.x and after) there is no state and domid reported
for inactive domains. When initially creating connections this is
handled in various places by assigning domain->id = -1.
But once an instance has been running, the id is set to the current
domain id. And it does not change when the instance is shut down.
So when querying the domain info, the hypervisor driver, which gets
asked first will indicate it cannot find information, then the
xend driver is asked and will set the status to NOSTATE because it
checks for the -1 domain id.
Checking domain/status for 0 seems to be more reliable for that.
One note: I am not sure whether the domain->id also should get set
back to -1 whenever any sub-driver thinks the instance is no longer
running.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=746007
BugLink: http://bugs.launchpad.net/bugs/929626
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 26e9ef476239e8cb79f819092c5aac4afdd47d0d)
(crobinso: Add Stefan to AUTHORS. maint only)
filename is not initialized to NULL while it's unconditionally freed in
the error path.
Signed-off-by: Philipp Hahn <hahn@univention.de>
(cherry picked from commit 360afebfb36cd7269b8a48db2e00e306bde0e641)
On CentOS5 with xen-3.0.3:
Program received signal SIGSEGV, Segmentation fault.
virFree (ptrptr=0x8) at util/memory.c:310
310 free(*(void**)ptrptr);
(gdb) bt
#0 virFree (ptrptr=0x8) at util/memory.c:310
#1 0x00002aaaaae167c8 in xenXMDomainDefineXML (conn=0x694e80, xml=0x6b2ce0 "P\fk") at xen/xm_internal.c:1199
#2 0x00002aaaaae070d7 in xenUnifiedDomainDefineXML (conn=0x8,
xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at xen/xen_driver.c:1524
#3 0x00002aaaaada7803 in virDomainDefineXML (conn=0x694e80,
xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at libvirt.c:7823
#4 0x0000000000426173 in cmdEdit (ctl=0x7fffffffb8e0, cmd=<value optimized out>) at virsh.c:14882
#5 0x000000000041c9ce in vshCommandRun (ctl=0x7fffffffb8e0, cmd=0x658c50) at virsh.c:17712
#6 0x000000000042c3b9 in main (argc=1, argv=<value optimized out>) at virsh.c:19317
Signed-off-by: Philipp Hahn <hahn@univention.de>
(cherry picked from commit 046b0a6972a9adaeb7227c75fbbdfe5cf0dad62f)
It just doesn't really make sense and confuses virt-manager
(cherry picked from commit efb0839c1d5471ab70ad81a36372c5cb6e5ed9a6)
Conflicts:
src/xenxs/xen_sxpr.c
On xen 4.1 I observed configurations that look like:
(image
(hvm
(kernel '')
(loader '/foo/bar')
))
The kernel element is there but unset. This leads to an empty <kernel/>
element in the XML and even worse makes us skip the boot order parsing
and therefore not emit a <boot device='$dev>'/> element which breaks CD
booting.
(cherry picked from commit dca1a6b46fecca57eac8914f30ad5a41a9f038fe)
otherwise a missing UUID in a domain config just shows:
error: An error occurred, but the cause is unknown
Now we have:
error: configuration file syntax error: config value uuid was missing
(cherry picked from commit c5d2984c4270d257a5c01c236ca086162fd2849d)
The stream lock is unlocked twice instead of being locked and then
unlocked. Probably a typo.
(cherry picked from commit 107f51b69c44b9902ed76ab0e33e89dde5d21cb1)
Conflicts:
AUTHORS
This patch adds another callback to a FDstream object. The original
callback is used by the daemon stream driver to handle events.
This callback is called if and only if the stream is about to be closed.
This might be used to handle cleanup steps after a fdstream exits. This
will be used later on in ensuring mutually exclusive access to consoles.
* src/fdstream.c:
- emit the callback, when stream is being closed
- add data structures needed to handle the callback
- add function to register callback
* src/fdstream.h:
- define function prototypes for the callback
(cherry picked from commit 0c4bfdda42f176633a9db7c52703802e3f0123fe)
This patch causes the fdstream driver to call the stream event callback
if virStreamAbort() is called on a stream using this driver.
A remote handler for a stream can only detect changes via stream events,
so this event callback is necessary in order to enable a daemon to abort
a stream in such a way that the client will see the change.
* src/fdstream.c:
- modify close function to call stream event callback
(cherry picked from commit 95fdc1bc2b397909b9cefacf9ff91924897f5af4)
Due to the asynchronous nature of streams, we might continue to
receive some stream packets from the server even after we have
shutdown the stream on the client side. These should be discarded
silently, rather than raising an error in the RPC layer.
* src/rpc/virnetclient.c: Discard stream data silently
(cherry picked from commit a38710bd652c1a4a79df7d4ef171d20ff322e566)
Very occasionally the sequence of events from poll would result
in getting a HANGUP on its own, instead of a HANGUP+READABLE
at the same time. In the former case we would send back an error
event to the client, but never send the empty packet to indicate
EOF.
(cherry picked from commit 1d46b2e900498a3f389fcbb89fc7b27d22f36d4a)
If we receive an error on the stream, set the EOF marker so
that any further (bogus) incoming data is dropped.
* src/rpc/virnetclientstream.c: Set EOF on stream
(cherry picked from commit bc61aa1211666d5b0c2930a69b6b9db17288f003)
Do not crash if virStreamFinish is called after error.
==11000== Invalid read of size 4
==11000== at 0x373A8099A0: pthread_mutex_lock (pthread_mutex_lock.c:51)
==11000== by 0x4C7CADE: virMutexLock (threads-pthread.c:85)
==11000== by 0x4D57C31: virNetClientStreamRaiseError (virnetclientstream.c:203)
==11000== by 0x4D385E4: remoteStreamFinish (remote_driver.c:3541)
==11000== by 0x4D182F9: virStreamFinish (libvirt.c:14157)
==11000== by 0x40FDC4: cmdScreenshot (virsh.c:3075)
==11000== by 0x42BA40: vshCommandRun (virsh.c:14922)
==11000== by 0x42ECCA: main (virsh.c:16381)
==11000== Address 0x59b86c0 is 16 bytes inside a block of size 216 free'd
==11000== at 0x4A06928: free (vg_replace_malloc.c:427)
==11000== by 0x4C69E2B: virFree (memory.c:310)
==11000== by 0x4D57B56: virNetClientStreamFree (virnetclientstream.c:184)
==11000== by 0x4D3DB7A: remoteDomainScreenshot (remote_client_bodies.h:1812)
==11000== by 0x4CFD245: virDomainScreenshot (libvirt.c:2903)
==11000== by 0x40FB73: cmdScreenshot (virsh.c:3029)
==11000== by 0x42BA40: vshCommandRun (virsh.c:14922)
==11000== by 0x42ECCA: main (virsh.c:16381)
(cherry picked from commit be5ec76630c4af83404e8fbf2b5a6b7cb46656e7)
commit 984840a2c292402926ad100aeea33f8859ff31a9 removed the
notification of waiting calls when VIR_NET_CONTINUE messages
arrive. This was to fix the case of a virStreamAbort() call
being prematurely notified of completion.
The problem is that sometimes there are dummy calls from a
virStreamRecv() call waiting that *do* need to be notified.
These dummy calls should have a status VIR_NET_CONTINUE. So
re-add the notification upon VIR_NET_CONTINUE, but only if
the waiter also has a status of VIR_NET_CONTINUE.
* src/rpc/virnetclient.c: Notify waiting call if stream data
arrives
* src/rpc/virnetclientstream.c: Mark dummy stream read packet
with status VIR_NET_CONTINUE
(cherry picked from commit cb61009236a96f16fa7eabc92f5d6ed5f6313163)
Ever since commit c964b6a, make was trying to find the timestamp
of '""./apibuild.py".stamp"', but only touching 'apibuild.py.stamp',
and thus always rebuilding. Reported by Daniel P. Berrange.
* docs/Makefile.am (APIBUILD, APIBUILD_STAMP): Omit bogus quotes.
(cherry picked from commit c0057d9a49f6aead9a893c33069d2a11c03bc1e8)
