A flaw was found in libvirt. A refactor of the code fetching the list of interfaces for multiple APIs introduced a corner case on platforms where allocating 0 bytes of memory results in a NULL pointer. This corner case would lead to a NULL-pointer dereference and subsequent crash of virtinterfaced. This issue could allow clients connecting to the read-only socket to crash the virtinterfaced daemon.
A flaw was found in libvirt. The virStoragePoolObjListSearch function does not return a locked pool as expected, resulting in a race condition and denial of service when attempting to lock the same object from another thread. This issue could allow clients connecting to the read-only socket to crash the libvirt daemon.
A vulnerability was found in libvirt. This security flaw ouccers due to repeatedly querying an SR-IOV PCI device's capabilities that exposes a memory leak caused by a failure to free the virPCIVirtualFunction array within the parent struct's gautoptr cleanup.
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).
A use-after-free flaw was found in libvirt. The qemuMonitorUnregister() function in qemuProcessHandleMonitorEOF is called using multiple threads without being adequately protected by a monitor lock. This flaw could be triggered by the virConnectGetAllDomainStats API when the guest is shutting down. An unprivileged client with a read-only connection could use this flaw to perform a denial of service attack by causing the libvirt daemon to crash.
A flaw was found in the libvirt virStoragePoolLookupByTargetPath API. The storagePoolLookupByTargetPath() function does not properly release a locked object (virStoragePoolObj) on ACL permission failure. Clients connecting to the read-write socket with limited ACL permissions could use this flaw to acquire the lock and prevent other users from accessing storage pool/volume APIs, resulting in a denial of service condition.
Upstream fix: https://libvirt.org/git/?p=libvirt.git;a=commit;h=447f69dec47e1b0bd15ecd7cd49a9fd3b050fb87
A flaw was found in libvirt in the virConnectListAllNodeDevices API in versions before 7.0.0. It only affects hosts with a PCI device and driver that supports mediated devices (e.g., GRID driver). This flaw could be used by an unprivileged client with a read-only connection to crash the libvirt daemon by executing the 'nodedev-list' virsh command. The highest threat from this vulnerability is to system availability.
A flaw was found in libvirt while it generates SELinux MCS category pairs for VMs' dynamic labels. This flaw allows one exploited guest to access files labeled for another guest, resulting in the breaking out of sVirt confinement. The highest threat from this vulnerability is to confidentiality and integrity.
A double free memory issue was found to occur in the libvirt API responsible for requesting information about network interfaces of a running QEMU domain. This flaw affects the polkit access control driver. Specifically, clients connecting to the read-write socket with limited ACL permissions could use this flaw to crash the libvirt daemon, resulting in a denial of service, or potentially escalate their privileges on the system. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A flaw was found in libvirt, where it leaked a file descriptor for /dev/mapper/control into the QEMU process. This file descriptor allows for privileged operations to happen against the device-mapper on the host. This flaw allows a malicious guest user or process to perform operations outside of their standard permissions, potentially causing serious damage to the host operating system. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.
An information disclosure vulnerability was found in libvirt in versions before 6.3.0. HTTP cookies used to access network-based disks were saved in the XML dump of the guest domain. This flaw allows an attacker to access potentially sensitive information in the domain configuration via the dumpxml command.
A flaw was found in libvirt. A pool created without a target path may lead to segmentation fault and denial of service. This issue may be triggered by a read only user.
References:
https://bugzilla.redhat.com/showbug.cgi?id=1790725
A flaw was found in the way Libvirtd daemon issued the 'suspend' command to a QEMU guest-agent running inside a guest. It holds a monitor job while issuing the 'suspend' command to a guest-agent. A malicious guest-agent may use this flaw to block the Libvirt daemon indefinitely resulting in a DoS scenario.
Upstream patch: --------------- -> https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=a663a860819287e041c3de672aad1d8543098ecc
It was discovered that libvirtd before versions 4.10.1 and 5.4.1 would permit read-only clients to use the virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which would be accessed with the permissions of the libvirtd process. An attacker with access to the libvirtd socket could use this to probe the existence of arbitrary files, cause denial of service or cause libvirtd to execute arbitrary programs.
A vulnerability was found in libvirt >= 4.1.0 in the virtlockd-admin.socket and virtlogd-admin.socket systemd units. A missing SocketMode configuration parameter allows any user on the host to connect using virtlockd-admin-sock or virtlogd-admin-sock and perform administrative tasks against the virtlockd and virtlogd daemons.
A vulnerability was found in libvirt versions >= 4.8.0. An information exposure allows to retrieve the guest hostname under readonly mode
References: https://bugzilla.redhat.com/showbug.cgi?id=1692619
An incomplete fix for CVE-2018-5748 that affects QEMU monitor leading to a resource exhaustion but now also triggered via QEMU guest agent.
Upstream patch:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=fbf31e1a4cd19d6f6e33e0937a009775cd7d9513
Last updated 25 August 2025
A flaw was found in Qemu. A lack of restriction for the amount of data read by QEMU Monitor socket can lead to denial of service by exhaustion of memory resources.
References:
https://www.redhat.com/archives/libvir-list/2017-December/msg00749.html
Last updated 25 August 2025
Last updated 25 August 2025
Description of the problem:
Domblkstat is possible even with read-only connection, so whenever migration with spice is done and domblkstat gets called at the same time as qemuMonitorGetSpiceMigrationStatus(), there is certain possibility that the daemon crashes.
An unprivileged user able to issue commands to running libvirtd could use this flaw to crash libvirtd and prevent more privileged clients from working correctly.
Upstream fix: http://libvirt.org/git/?p=libvirt.git;a=commit;h=484cc321
Acknowledgements:
This issue was discovered by Marian Krcmarik of Red Hat.
Race condition in the virNetServerClientStartKeepAlive function in libvirt before 1.2.1 allows remote attackers to cause a denial of service (libvirtd crash) by closing a connection before a keepalive response is sent.
Multiple race conditions in the (1) virDomainBlockStats, (2) virDomainGetBlockInf, (3) qemuDomainBlockJobImpl, and (4) virDomainGetBlockIoTune functions in libvirt before 1.2.1 do not properly verify that the disk is attached, which allows remote read-only attackers to cause a denial of service (libvirtd crash) via the virDomainDetachDeviceFlags command.
The lxcDomainGetMemoryParameters method in lxc/lxcdriver.c in libvirt 1.0.5 through 1.2.0 does not properly check the status of LXC guests when reading memory tunables, which allows local users to cause a denial of service (NULL pointer dereference and libvirtd crash) via a guest in the shutdown status, as demonstrated by the "virsh memtune" command.
Eric Blake from Red Hat reports that ever since libvirt 1.1.1 added ACL domain:getattr filtering for commands like virConnectListAllDomains, we have had a latent problem that the use of virConnectDomainEventRegister() and virConnectDomainEventRegisterAny() can be used to learn about virDomainPtr objects that should have been inaccessible to the user. It is not a problem if you are not using ACLs; also, it is partially mitigated by the fact that any domain that does not trigger an event in the timeframe where the attacker maintains their event callback will not be leaked.
Once an attacker has learned about a domain by bypassing domain:getattr, they could perform other actions on the domain if there were not ACLs to filter those actions too, such as starting and stopping the domain.
An invalid free flaw in the libxl driver in libvirt resulted in libvirt crashing if "virsh numatune" was run on an inactive domain. It may be possible, but unlikely, for an attacker to leverage this flaw for arbitrary code execution.
This issue affects the version of libvirt in Fedora 20. It does not affect the versions of libvirt in Red Hat Enterprise Linux 5 and 6 as those versions do not use libxl.
The LXC driver (lxc/lxcdriver.c) in libvirt 1.0.1 through 1.2.1 allows local users to (1) delete arbitrary host devices via the virDomainDeviceDettach API and a symlink attack on /dev in the container; (2) create arbitrary nodes (mknod) via the virDomainDeviceAttach API and a symlink attack on /dev in the container; and cause a denial of service (shutdown or reboot host OS) via the (3) virDomainShutdown or (4) virDomainReboot API and a symlink attack on /dev/initctl in the container, related to "paths under /proc/$PID/root" and the virInitctlSetRunLevel function.
If users haven't configured guest agent then qemuAgentCommand() will dereference a NULL 'mon' pointer.
A remote user able to issue commands to libvirt daemon could use this flaw to crash libvirtd.
References: https://bugzilla.redhat.com/showbug.cgi?id=984821 https://www.redhat.com/archives/libvir-list/2013-July/msg00992.html
Acknowledgements:
This issue was discovered by Alex Jia of Red Hat.
A part of the returned monitor response was freed twice and caused crashes of the daemon when using guest agent cpu count retrieval.
A remote user able to issue commands to libvirt daemon could use this flaw to crash libvirtd or, potentially, escalate their privilages to that of libvirtd process.
References: https://bugzilla.redhat.com/showbug.cgi?id=984821 https://www.redhat.com/archives/libvir-list/2013-July/msg01035.html
Acknowledgements:
This issue was discovered by Petr Krempa of Red Hat.