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 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 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 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.

It has been found that sending RPC message with an event as the RPC number, or RPC number that falls into gap in the RPC dispatch table, can lead to libvirtd accessing memory at page zero. A remote attacker could use this flaw to crash libvirtd (DoS).

Proposed upstream fix: https://www.redhat.com/archives/libvir-list/2012-September/msg00843.html

It has been found that sending crafted RPC command with nparams set to 0 can lead to libvirtd accessing random memory, possibly leading to crash. A remote attacker could use this flaw to crash libvirtd (DoS).

Upstream proposed fix: https://www.redhat.com/archives/libvir-list/2012-July/msg01650.html

libvirt, possibly before 0.9.12, does not properly assign USB devices to virtual machines when multiple devices have the same vendor and product ID, which might cause the wrong device to be associated with a guest and might allow local users to access unintended USB devices.