| Reported on: | 20150313 |
|---|---|
| Published on: | 20150316 |
| Fixed on: | 20150316 |
| Reported by: | Eric Blake |
|---|---|
| Patched by: | Eric Blake |
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.
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.
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.