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: NEric 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: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6b27d3e)

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)

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 b7ff9e69)

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 b7ff9e69)

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 307f3635)

Commit a56c3470 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 a22a36e8)

Conflicts:
	tests/seclabeltest.c

This is 0.9.6-maint only, but similar changes are upstream

This is for v0.9.6 maint only, though similar changes are upstream.

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 bde32b1a)

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: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit 22ec6000)

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 6039a2cb)

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 f12e1396)

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 e925ea31)

Conflicts:
	.gnulib - skip all intermediate commits touching this file
	bootstrap - likewise

Pick up recent gnulib improvements.

* .gnulib: Update to latest.
* bootstrap: Resync.
* bootstrap.conf (gnulib_tool_option_extras): Adjust to bootstrap
changes.
* gnulib/lib/Makefile.am: Likewise.
(cherry picked from commit 29db7a00)

Conflicts:
	.gnulib - skip all intermediate commits touching this file
	bootstrap.conf - likewise (especially skip commit f7bd00c1)

(cherry picked from commit f94d9c57)

* libvirt.pc.in: Add missing '/api/' in path
* libvirt.spec.in, mingw32-libvirt.spec.in: s/apis/api/
(cherry picked from commit 5452e88c)

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 32617617).
(cherry picked from commit b19c236d)

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 746ff701)

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 f3cfc7c8)

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 da831afc)

Conflicts:

	src/util/command.c

virCommandRunAsync() will set errfd if it succeed. We should
close it if virFDStreamOpenInternal() fails.
(cherry picked from commit 655cffa0)

If the system does not support bypass cache, we will close fd,
but it is uninitialized.
(cherry picked from commit 0a045f01)

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 03b804a2)

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 1ebd52cb)

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 2c195fdb)

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: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 80710c69)

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: NStefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 10c31135)

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/929626Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 26e9ef47)

(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: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit 360afebf)

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: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit 046b0a69)

It just doesn't really make sense and confuses virt-manager
(cherry picked from commit efb0839c)

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 dca1a6b4)

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 c5d2984c)