It was found that when a disk is attached to a disk "live" (thus not written into the persistent configuration) and then the statistics for the disks are requested from the persistent configuration, index to the array is determined from the live configuration but used in the persistent. A remote attacker able to establish a read-only connection to libvirtd could use this flaw to crash libvirtd or, potentially, leak memory from the libvirtd process. Acknowledgements: This issue was discovered by Luyao Huang of Red Hat.
Statement: This issue does not affect the versions of libvirt packages as shipped with Red Hat Enterprise Linux 5. This issue does affect the versions of libvirt packages as shipped with Red Hat Enterprise Linux 6 and 7. Future updates may address this issue in the respective Red Hat Enterprise Linux releases.
Upstream commit: http://libvirt.org/git/?p=libvirt.git;a=commit;h=3e745e8f775dfe6f64f18b5c2fe4791b35d3546b
IssueDescription: An out-of-bounds read flaw was found in the way libvirt's qemuDomainGetBlockIoTune() function looked up the disk index in a non-persistent (live) disk configuration while a persistent disk configuration was being indexed. A remote attacker able to establish a read-only connection to libvirtd could use this flaw to crash libvirtd or, potentially, leak memory from the libvirtd process.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2014:1352 https://rhn.redhat.com/errata/RHSA-2014-1352.html
Created libvirt tracking bugs for this issue: Affects: fedora-all [bug 1160823]
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2014:1873 https://rhn.redhat.com/errata/RHSA-2014-1873.html
libvirt-1.1.3.8-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.