CVE-2013-0242 in glibc's regex() can cause a DoS in any daemon
that runs a regex search on user input while in a multibyte locale.
I'm not sure how hard it would be to trigger such a setup for
libvirtd, but rather than risk things, we can avoid the issue:
gnulib has worked around the problem, and by updating to the latest
gnulib, we can avoid the bug even on platforms where glibc has yet
to be patched.

* .gnulib: Update to latest, for various fixes, including regex.
* bootstrap: Resync from upstream.

It's simpler to render and it prevents wrapping the line too early
because of the table spacing, border et cetera.

When a function has no associated information to one of its
arguments or its return type we report it and stop with an error.

In commit 3ac26e26 parameter "path" was
renamed to "disk" but this change was not reflected in the documentation.

Additionally, documentation of the "opaque" parameter was missing.

Add support for QEMU -add-fd command line parameter detection.
This intentionally rejects qemu 1.2, where 'add-fd' QMP did
not allow full control of set ids, and where there was no command
line counterpart, but accepts qemu 1.3.
Signed-off-by: NEric Blake <eblake@redhat.com>

Add entry points for calling the qemu 'add-fd' and 'remove-fd'
monitor commands.  There is no entry point for 'query-fdsets';
the assumption is that a developer can use
 virsh qemu-monitor-command domain '{"execute":"query-fdsets"}'
when debugging issues, and that meanwhile, libvirt is responsible
enough to remember what fds it associated with what fdsets.
Likewise, on the 'add-fd' command, it is assumed that libvirt
will always pass a set id, rather than letting qemu autogenerate
the next available id number.

* src/qemu/qemu_monitor.c (qemuMonitorAddFd, qemuMonitorRemoveFd):
New functions.
* src/qemu/qemu_monitor.h (qemuMonitorAddFd, qemuMonitorRemoveFd):
New prototypes.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONAddFd)
(qemuMonitorJSONRemoveFd): New functions.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONAddFd)
(qemuMonitorJSONRemoveFd): New prototypes.

While testing QMP, I used a simple qemu session of
'qemu-kvm -M none -nodefaults -nographic -qmp stdio'
for some experiments.  But it took me far too long to remember
the magic invocation to unlock QMP into accepting normal commands.
While I was able to grep libvirt sources and easily find where
libvirt expects the normal "QMP" greeting, I could not find the
proper reply to that greeting nearby.

Reading the testsuite didn't help either, since there we don't
emulate the mandatory handshake.  But since my grep hit the
testsuite, adding a bit of documentation will make it much easier
to jog my memory in the future.

* tests/qemumonitortestutils.c (QEMU_JSON_GREETING): Mention that
the normal counterpart reply is skipped.

The macro was made to help installing broken packages that did not use
DESTDIR correctly by overriding individual path variables (prefix,
sysconfdir, ...). Newer rpm provides fixed make_install macro that calls
make install with just the correct DESTDIR, however it is not available
everywhere (e.g., RHEL 5 does not have it). On the other hand the
make_install macro is simple and straightforward enough for us to use
its expansion directly.

Without these two string changes in generator.py, the
virGetLastError wrapper does not get created in
/usr/share/pyshared/libvirt.py.  Noticed when running
tests with virt-install.
Signed-off-by: NSerge Hallyn <serge.hallyn@ubuntu.com>

Sources for securityselinuxlabeltest are only defined if qemu driver is
enabled so we should not try to build the test if qemu driver is
disabled.

When an exception happened inside the try clause in serialize_function,
a new exception was raised in the except clause subsequently:

Traceback (most recent call last):
  File "./apibuild.py", line 2529, in <module>
    rebuild("libvirt")
  File "./apibuild.py", line 2513, in rebuild
    builder.serialize()
  File "./apibuild.py", line 2467, in serialize
    self.serialize_function(output, function)
  File "./apibuild.py", line 2208, in serialize_function
    self.warning("Failed to save function %s info: " % name, `id.info`)
TypeError: warning() takes exactly 2 arguments (3 given)

Use the correct number of arguments for self.warning and print the
original exception to stderr.

Way back when I started making changes for Coverity messages my first set
were to a bunch of CHECKED_RETURN errors.  In particular virAsprintf() had
a few callers that Coverity noted didn't check their return (although some
did check if the buffer being printed to was NULL or not).

It was suggested at the time as a further patch an ATTRIBUTE_RETURN_CHECK
should be added to virAsprintf(), see:

https://www.redhat.com/archives/libvir-list/2013-January/msg00120.html

This patch does that and fixes a few more instances not found by Coverity
that failed the check.

https://bugzilla.redhat.com/show_bug.cgi?id=905708

Only the first 12 bits should be set in the mask for this range. All
addresses between 172.16.0.0 and 172.31.255.255 are private.

When a disk-only snapshot is requested the domain is treated as if it
was offline. This forbids to mix memory checkpoints with the DISK_ONLY
flag.

This patch improves the error message and mentions the restriction in
the virsh man page.

After one last-minute change, only HACKING was updated and not
hacking.html.in, so this patch synchronizes that.

* configure.ac docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: updated localizations

When doing checks with automake, there are '<testname>.trs' files left
behind, that might or might not be usable, however these show up in
'git status' even though we definitely don't want them to be tracked
in the repository'.  Automake adds the '--trs-files' option by default
since commit 0c81b43f711fb861f04227ced8dba889596d9c43 [1], which
consequently (from 1.13 in my case) started leaving these files behind
along with '<testname>.log' files as well (which we already ignore).

[1] http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=0c81b43

Adding dots inside "exempli gratia" where missing.  While on that, I
took the liberty of changing it where found with simple grep.

Commit 60b176c3 introduced a bug that
when editing an XML with cputune similar to this:

...
  <vcpu placement='static' current='1'>2</vcpu>
  <cputune>
    <vcpupin vcpu="1" cpuset="0"/>
  </cputune>
...

results in formatted XML that looks like this:

...
  <vcpu placement='static' current='1'>2</vcpu>
  <cputune>
  </cputune>
...

That is caused by a condition depending on def->cputune.vcpupin being
set rather than checking def->cputune.nvcpupin.  Notice that nvcpupin
can be 0 and vcpupin can still be allocated since it's a pointer to an
array, so no harm done there.

I also changed it on other places in the code where it depended on the
wrong variable.

Commit f24404a3 renamed virterror.c to
virerror.c but forgot to change the reference in this file.

Setting the log output prefix to 0 is not supported and in fact results
in the following message:
warning : virLogParseOutputs:1021 : Ignoring invalid log output setting.

Whenever libvirt version changes in configure.ac, we need to regenerate
man pages so that they contain correct version info.

def->cpumask is a bitmap and needs to be freed by virBitmapFree.

https://bugzilla.redhat.com/show_bug.cgi?id=894723

Currently, if qemuProcessStart() succeeds, but it's decompression
binary that returns nonzero status, we don't kill the qemu process,
but remove it from internal domain list, leaving the qemu process
hanging around totally uncontrolled.

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

The "volName" will be used by later patch.

The RE for data type "name" storagepool.rng uses is same with
"genericName" in basictypes.rng.

https://bugzilla.redhat.com/show_bug.cgi?id=892289

It seems like with new udev within guest OS, the tray is locked,
so we need to:
- 'eject'
- wait for tray to open
- 'change'

Moreover, even when doing bare 'eject', we should check for
'tray_open' as guest may have locked the tray. However, the
waiting phase shouldn't be unbounded, so I've chosen 10 retries
maximum, each per 500ms. This should give enough time for guest
to eject a media and open the tray.

Commit f0aa4935 missed a file.

* src/libvirt_driver_modules.syms: Add editor hint.

Adjust the macros to free memory allocated during various calls to
perform the check if parameter is NULL prior to really freeing and to
set the pointer to NULL after done freeing.

Resolve a false positive from 'vboxIIDFromUUID_v2_x()'. The code sets
'iid->value = &iid->backing' unconditionally prior to calling 'nsIDFromChar()'.
The 'vboxIIDUnalloc_v2_x()' checks iid->value to not be &iid->backing. The
iid->backing is a static buffer within the initialized structure.

The flag causes the XML of the disk that would be attached to be printed
instead.

Since libxl provides the domain ID in the event handler callback,
find the domain object based on the ID.  This approach prevents
processing the callback on a domain that has already been reaped.

Also, similar to the xl implementation, ignore the SUSPEND shutdown
reason.  By calling libxl_domain_suspend(), we know a shutdown
event with SUSPEND reason will be generated, but it can be safely
ignored since any subsequent cleanup will be done by the callers.

libxlDoDomainSave() was removing non-persistent domains, but
required callers to have the virDomainObj locked.  Callers could
potentially unlock an already freed virDomainObj.  Move this
logic to the callers of libxlDoDomainSave().

I've noticed that libxl can invoke timeout reregister/modify hooks
after returning from libxl_ctx_free.  Explicitly remove the
timeouts before freeing the libxl ctx to avoid executing hooks on
stale objects.

It is possible to destroy and cleanup a VM, resulting in freeing the
libxlDomainObjPrivate object and associated libxl ctx, before all fds and
timeouts have been deregistered and destroyed.

Fix this race by incrementing the reference count on libxlDomainObjPrivate
for each fd and timeout registration.  Only when all fds and timeouts are
deregistered and destroyed will the libxlDomainObjPrivate be destroyed.