Libvirt Security Notice: LSN-2015-0002 ====================================== Summary: small memory leak in ListAll APIs Reported on: 20150313 Published on: 20150316 Fixed on: 20150316 Reported by: Eric Blake <eblake@redhat.com> Patched by: Eric Blake <eblake@redhat.com> Description ----------- The interfaces remoteDispatchConnectListAllDomains, remoteDispatchDomainListAllSnapshots, remoteDispatchDomainSnapshotListAllChildren, remoteDispatchConnectListAllStoragePools, remoteDispatchStoragePoolListAllVolumes, remoteDispatchConnectListAllNetworks, remoteDispatchConnectListAllInterfaces, remoteDispatchConnectListAllNodeDevices, remoteDispatchConnectListAllNWFilters, remoteDispatchConnectListAllSecrets, and remoteDispatchNetworkGetDHCPLeases each have a guarantee that on a successful return, an array with a trailing NULL slot will be allocated, with the array size at least one larger than the return value. However, when using a remote connection where any of these calls returned a result of 0, the allocated array was leaked in the libvirtd server side of the API call. Impact ------ Since each ListAll API call is accessible to read-only clients, a client could repeatedly call the APIs to leak memory and attempt turning it into an out-of-memory denial of service against more privileged clients. In practice, though, since the leak is typically only 8 bytes per API call, an out-of-memory condition is unlikely to occur unless the client is calling the API so frequently as to be obvious that the client is attempting a denial of service long before memory is exhausted, so this vulnerability was not assigned a CVE. Workaround ---------- It is possible to guarantee that a memory leak cannot be escalated into a denial of service attack by preventing read-only connections and avoiding the use of fine-grained Access Control Lists (although this does not prevent the leaks, such a problem is no longer a security attack). Meanwhile, monitoring the libvirtd process for unexpected memory usage can be used to detect if any client is intentionally trying to exploit a memory leak, where restarting libvirtd is effective at avoiding issues where an eventual out-of-memory condition would cause adverse behavior. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v1.2.8 Broken in: v1.2.9 Broken in: v1.2.10 Broken in: v1.2.11 Broken in: v1.2.12 Broken in: v1.2.13 Fixed in: v1.2.14 Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: 3c2ff5029b83c9b33be0f1607a3c61f4f5850612 Branch: v1.2.8-maint Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: 4fc4f669eb6a1d776b917d410b6db46e09b6feed Branch: v1.2.9-maint Broken in: v1.2.9.1 Broken in: v1.2.9.2 Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: b9dacdd4d992ba1e5aab2e0189cf64b36a1a7e13 Branch: v1.2.10-maint Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: 70461a11b3410053b89c8c9309e011ce4f62bc07 Branch: v1.2.11-maint Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: b175298be8e92eb3d7883fa3927b97db04d449be Branch: v1.2.12-maint Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: 34538870c770515fc38fa3c71f39e8765113316d Branch: v1.2.13-maint Broken by: 4f25146bf4335cb2b1b31c07dab39e26458bdf61 Fixed by: 117f60ca53eb36aa7751573ac274850bd96a4799 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org