Race condition in the virNetServerClientStartKeepAlive function in libvirt before 1.2.1 allows remote attackers to cause a denial of service (libvirtd crash) by closing a connection before a keepalive response is sent.

Multiple race conditions in the (1) virDomainBlockStats, (2) virDomainGetBlockInf, (3) qemuDomainBlockJobImpl, and (4) virDomainGetBlockIoTune functions in libvirt before 1.2.1 do not properly verify that the disk is attached, which allows remote read-only attackers to cause a denial of service (libvirtd crash) via the virDomainDetachDeviceFlags command.

An invalid free flaw in the libxl driver in libvirt resulted in libvirt crashing if "virsh numatune" was run on an inactive domain. It may be possible, but unlikely, for an attacker to leverage this flaw for arbitrary code execution.

This issue affects the version of libvirt in Fedora 20. It does not affect the versions of libvirt in Red Hat Enterprise Linux 5 and 6 as those versions do not use libxl.

The LXC driver (lxc/lxcdriver.c) in libvirt 1.0.1 through 1.2.1 allows local users to (1) delete arbitrary host devices via the virDomainDeviceDettach API and a symlink attack on /dev in the container; (2) create arbitrary nodes (mknod) via the virDomainDeviceAttach API and a symlink attack on /dev in the container; and cause a denial of service (shutdown or reboot host OS) via the (3) virDomainShutdown or (4) virDomainReboot API and a symlink attack on /dev/initctl in the container, related to "paths under /proc/$PID/root" and the virInitctlSetRunLevel function.

The lxcDomainGetMemoryParameters method in lxc/lxcdriver.c in libvirt 1.0.5 through 1.2.0 does not properly check the status of LXC guests when reading memory tunables, which allows local users to cause a denial of service (NULL pointer dereference and libvirtd crash) via a guest in the shutdown status, as demonstrated by the "virsh memtune" command.

Description of the problem:

Domblkstat is possible even with read-only connection, so whenever migration with spice is done and domblkstat gets called at the same time as qemuMonitorGetSpiceMigrationStatus(), there is certain possibility that the daemon crashes.

An unprivileged user able to issue commands to running libvirtd could use this flaw to crash libvirtd and prevent more privileged clients from working correctly.

Upstream fix: http://libvirt.org/git/?p=libvirt.git;a=commit;h=484cc321

Acknowledgements:

This issue was discovered by Marian Krcmarik of Red Hat.

A part of the returned monitor response was freed twice and caused crashes of the daemon when using guest agent cpu count retrieval.

A remote user able to issue commands to libvirt daemon could use this flaw to crash libvirtd or, potentially, escalate their privilages to that of libvirtd process.

References: https://bugzilla.redhat.com/showbug.cgi?id=984821 https://www.redhat.com/archives/libvir-list/2013-July/msg01035.html

Acknowledgements:

This issue was discovered by Petr Krempa of Red Hat.

If users haven't configured guest agent then qemuAgentCommand() will dereference a NULL 'mon' pointer.

A remote user able to issue commands to libvirt daemon could use this flaw to crash libvirtd.

References: https://bugzilla.redhat.com/showbug.cgi?id=984821 https://www.redhat.com/archives/libvir-list/2013-July/msg00992.html

Acknowledgements:

This issue was discovered by Alex Jia of Red Hat.