The virBitmapParse function in util/virbitmap.c in libvirt before 1.1.2 allows context-dependent attackers to cause a denial of service (out-of-bounds read and crash) via a crafted bitmap, as demonstrated by a large nodeset value to numatune.
A flaw was found in libvirt where libvirtd could crash due to how XML was parsed [1]. With the introduction of ACL permissions in libvirt 1.1.0, this flaw could be manipulated to allow a remote user with connect:read privileges to elevate them to the more permissive domain:write privilege.
This vulnerability was introduced in libvirt 1.1.0.
[1] https://bugzilla.redhat.com/showbug.cgi?id=1012196;
The remoteClientFreeFunc function in daemon/remote.c in libvirt before 1.1.3, when ACLs are used, does not set an identity, which causes event handler removal to be denied and remote attackers to cause a denial of service (use-after-free and crash) by registering an event handler and then closing the connection.
The 'stats' variable in remoteDispatchDomainMemoryStats function was not initialized to NULL, so if some early validation of the RPC call fails, it is possible to jump to the 'cleanup' label and VIRFREE an uninitialized pointer.
A remote user able to issue commands to libvirt daemon could use this flaw to crash libvirtd.
Acknowledgements:
This issue was discovered by Daniel P. Berrange of Red Hat.
libvirt 1.1.0 and 1.1.1 allows local users to cause a denial of service (memory consumption) via a large number of domain migrate parameters in certain RPC calls in (1) daemon/remote.c and (2) remote/remotedriver.c.
The virFileNBDDeviceAssociate function in util/virfile.c in libvirt 1.1.2 and earlier allows remote authenticated users to cause a denial of service (uninitialized pointer dereference and crash) via unspecified vectors.
The virSecurityManagerSetProcessLabel function in libvirt 0.10.2.7, 1.0.5.5, and 1.1.1, when the domain has read an uid:gid label, does not properly set group memberships, which allows local users to gain privileges.
Commit 632180d1 introduced memory corruption in xenDaemonListDefinedDomains() by starting to populate the names array at index -1, causing all sorts of havoc in libvirtd such as aborts like the following
Error in /usr/sbin/libvirtd': double free or corruption (out): 0x00007fffe00ccf20
The xenDaemonListDefinedDomains() function is reached by the virConnectListDefinedDomains() public API, which can be used on read-only connections.
Introduced in: libvirt v1.1.1
Introduced by: http://libvirt.org/git/?p=libvirt.git;a=commit;h=632180d1
Fixed by: http://libvirt.org/git/?p=libvirt.git;a=commit;h=0e671a16
libvirt 1.0.0 through 1.2.x before 1.2.5, when fine grained access control is enabled, allows local users to read arbitrary files via a crafted XML document containing an XML external entity declaration in conjunction with an entity reference to the (1) virDomainDefineXML, (2) virNetworkCreateXML, (3) virNetworkDefineXML, (4) virStoragePoolCreateXML, (5) virStoragePoolDefineXML, (6) virStorageVolCreateXML, (7) virDomainCreateXML, (8) virNodeDeviceCreateXML, (9) virInterfaceDefineXML, (10) virStorageVolCreateXMLFrom, (11) virConnectDomainXMLFromNative, (12) virConnectDomainXMLToNative, (13) virSecretDefineXML, (14) virNWFilterDefineXML, (15) virDomainSnapshotCreateXML, (16) virDomainSaveImageDefineXML, (17) virDomainCreateXMLWithFiles, (18) virConnectCompareCPU, or (19) virConnectBaselineCPU API method, related to an XML External Entity (XXE) issue. NOTE: this issue was SPLIT from CVE-2014-0179 per ADT3 due to different affected versions of some vectors.
libvirt 0.7.5 through 1.2.x before 1.2.5 allows local users to cause a denial of service (read block and hang) via a crafted XML document containing an XML external entity declaration in conjunction with an entity reference to the (1) virConnectCompareCPU or (2) virConnectBaselineCPU API method, related to an XML External Entity (XXE) issue. NOTE: this issue was SPLIT per ADT3 due to different affected versions of some vectors. CVE-2014-5177 is used for other API methods.
A flaw was found in the libvirt nwfilter driver. The virNWFilterObjListNumOfNWFilters method failed to acquire the driver->nwfilters mutex before iterating over virNWFilterObj instances. There was no protection to stop another thread from concurrently modifying the driver->nwfilters object. This flaw allows a malicious, unprivileged user to exploit this issue via libvirt's API virConnectNumOfNWFilters to crash the network filter management daemon (libvirtd/virtnwfilterd).