A symlink-following vulnerability was found in libvirt's virFileChownFiles() function in src/util/virfile.c. This function is called from src/qemu/qemutpm.c to change ownership of the swtpm state directory when starting a QEMU domain.
The function used stat() (via virFileIsRegular()) and chown(), both of which follow symlinks. A process running as the confined swtpm user (tss) can plant a symlink inside the swtpm state directory pointing to an arbitrary file. When the root-level libvirt daemon starts the next domain, it calls virFileChownFiles() which follows the symlink and chowns the target file to the tss user. This allows escalation from the swtpm sandbox to root-level file ownership control.
The fix replaces stat()/chown() with lstat()/lchown() to avoid following symlinks on the final path component.
Upstream fix: https://gitlab.com/libvirt/libvirt/-/commit/801160fd414ca2cc402bc01ead09b7ed4c3b8f5b
A file permission vulnerability was found in libvirt's storage volume clone/convert path in src/storage/storageutil.c. The virStorageBackendCreateExecCommand() function ran qemu-img with umask 0 on non-NETFS local storage paths, causing newly created volume images to be world-readable (mode 0644) during the copy operation. libvirt only tightened the file permissions via chmod() after qemu-img completed, creating a window where the full guest disk contents could be read by any local user.
This is the same class of issue as CVE-2025-13193. A local attacker could exploit this race window to read sensitive guest disk contents, resulting in information disclosure.
The fix moves the virCommandSetUmask() call to apply unconditionally to all code paths, ensuring qemu-img creates files with restrictive permissions from the outset.
Upstream fix: https://gitlab.com/libvirt/libvirt/-/commit/69335a484768d550854da1133d5490074695e825
A flaw was found in libvirt. The network XML parser accepts XML numeric character references for line breaks ( / ) in DNS TXT record value attributes and SRV record domain/target attributes without sanitization. The network driver writes these values directly into the line-oriented dnsmasq configuration file as txt-record= or srv-host= directives. An embedded newline terminates the intended directive and begins a new one under attacker control (e.g., dhcp-script=/bin/sh -c '<cmd>'), which dnsmasq executes as root when the virtual network is started. Under the default libvirt deployment model, read-write access to the libvirt socket is already root-equivalent, and the <dnsmasq:options> raw namespace already provides a documented mechanism for arbitrary directive injection, making this a hardening issue only. However, under non-default polkit fine-grained access control configurations that grant only network.write and network.start permissions, this could represent a privilege boundary violation.
A flaw was found in libvirt. The network XML parser accepts XML numeric character references for line breaks ( / ) in DNS TXT record value attributes and SRV record domain/target attributes without sanitization. The network driver writes these values directly into the line-oriented dnsmasq configuration file as txt-record= or srv-host= directives. An embedded newline terminates the intended directive and begins a new one under attacker control (e.g., dhcp-script=/bin/sh -c '<cmd>'), which dnsmasq executes as root when the virtual network is started. Under the default libvirt deployment model, read-write access to the libvirt socket is already root-equivalent, and the <dnsmasq:options> raw namespace already provides a documented mechanism for arbitrary directive injection, making this a hardening issue only. However, under non-default polkit fine-grained access control configurations that grant only network.write and network.start permissions, this could represent a privilege boundary violation.
A flaw was found in libvirt. External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.
A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks (https://libvirt.org/acl.html). A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.
Upstream issue: https://gitlab.com/libvirt/libvirt/-/issues/825
Patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LTGHU3S4JEMCF5KJNJGWWZ7F2CS6L5SG/
A buffer overflow flaw was found in libvirtproxy. libvirtproxy is set to run as a setuid root by default, so in theory this could allow for a local user to become root.
Normally the stack protector would prevent this from being an issue, but it seems that with gcc optimizations, the function in question is being inlined into main(), preventing the stack protector from catching this.
The original report can be found here: https://www.redhat.com/archives/libvir-list/2009-January/msg00699.html
The patch is here: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=2bb0657e28
A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks (https://libvirt.org/acl.html). A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.
Upstream issue: https://gitlab.com/libvirt/libvirt/-/issues/825
Patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LTGHU3S4JEMCF5KJNJGWWZ7F2CS6L5SG/