[Libvirt-announce] LSN-2015-0002: small memory leak in ListAll APIs

[Eric Blake]

        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 at redhat.com>
    Patched by: Eric Blake <eblake at 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