A flaw was found in libvirt. An unprivileged local user could exploit an integer overflow vulnerability in the NodeGetFreePages RPC handler. This flaw allows crafted values to bypass a size check, leading to an undersized memory buffer. Subsequently, real NUMA node data can overwrite this buffer. This heap buffer overflow can corrupt the root libvirt daemon's memory, potentially leading to a denial of service or local privilege escalation.
An integer overflow vulnerability was found in libvirt's NodeGetFreePages RPC handler in src/remote/remotedaemondispatch.c. The dispatcher computes a 32-bit product (pageslen cellCount) for both validation and memory allocation. While pageslen is XDR-capped at 1024, cellCount remains unbounded. The multiplication truncates modulo 2^32, allowing crafted values to bypass the guard check. The undersized buffer is then overwritten with real NUMA node data. The RPC call requires only connect:read ACL (lowest permission tier) and is accessible via the world-readable Unix socket (mode 0666) with no authentication for VIRCONNECTRO clients. An unprivileged local user could exploit this to corrupt the root libvirt daemon's heap, leading to denial of service or potentially local privilege escalation.
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. A local attacker, specifically a process running as the confined swtpm user, could exploit a symlink-following vulnerability in the virFileChownFiles() function. By planting a symbolic link within the swtpm state directory, the attacker could trick the root-level libvirt daemon into changing the ownership of an arbitrary file to the swtpm user. This allows for privilege escalation from the swtpm sandbox to root-level file ownership control.
libvips is a demand-driven, horizontally threaded image processing library. The heifsave operation could incorrectly determine the presence of an alpha channel in an input when it was not possible to determine the colour interpretation, known internally within libvips as "multiband". There aren't many ways to create a "multiband" input, but it is possible with a well-crafted TIFF image. If a "multiband" TIFF input image had 4 channels and HEIF-based output was requested, this led to libvips creating a 3 channel HEIF image without an alpha channel but then attempting to write 4 channels of data. This caused a heap buffer overflow, which could crash the process. This vulnerability is fixed in 8.16.1.
On Sun, Oct 22, 2023 at 09:19:59AM -0500, Bob Friesenhahn wrote: On Sat, 21 Oct 2023, Demi Marie Obenour wrote: For Rocky Linux Security SIG, the only relevant thing mentioned so far was possibly offering an OpenBSD pledge()-alike that other packages could use. However, I am skeptical any actually would, unless we also introduce such uses ourselves and maintain own "override" packages (replacing RHEL rebuild ones or those coming from EPEL, etc.) of such software. Initially, we are going to only create "override' packages for core or very commonly used/exposed components, and to do so only for specific good reasons. So stuff like e.g. ImageMagick/GraphicsMagick coming from EPEL and with most of its dependency libraries coming from AppStream repos, or e.g. GraphViz coming from AppStream, is unlikely to make the cut, at least not initially. Has deprecating ImageMagick and/or GraphicsMagick outright been considered? I don’t just mean the downstream packages, but the entire upstream projects, or at least the libraries. RHEL already deprecated ImageMagick several years ago and advised users to use GraphicsMagick (https://access.redhat.com/documentation/en-us/redhatenterpriselinux/7/html/7.7releasenotes/deprecatedfunctionality). Those users were confused given that many of the recipes they were using for ImageMagick did not work with GraphicsMagick. The solution for those users was to find a different way to install ImageMagick. One option would be to instead make an IPC call to a persistent daemon running in the background. That said, has wasm2c been considered? The best fix would be something that can make C code memory-safe, even if it comes at a performance hit of 4x or more (like SoftBound+CETS did). Stuff that cares about performance should be migrating to something like libvips or ImageFlow.
If neither of these are options, I think the entire library will need to be deprecated for eventual removal. The command-line tools can remain, but they can be much more strongly sandboxed than a library can, because they have the entire process to themselves. Any deprecations or sandboxing approaches which fail to understand and address the needs of the "user" will fail. Replacing package 'A' with package 'B', where package 'B' works totally differently, or performs different functions than package 'A' will fail because the users will not use it. That is true. Unfortunately, most Linux IPC mechanisms are not very secure since they rely on historical Unix privilege models to control access. If one can bypass access control on IPC, one can easily get root by sending malicious commands to systemd, so I don't think this is something to worry about. Common ways to assure security such as TLS usually result in a considerable reduction of performance. Solutions like Landlock seem useful for very restricted usage applications. Sandboxing solutions which work for any use of a program seem better than requiring a client/server model. The advantage of a client/server model is that it avoids a library having to spawn child processes, which was mentioned as a concern earlier. I agree that it is more effort than desirable. As the developer/maintainer of a complex C program (GraphicsMagick), I appreciate any advice on improvements which make it more suitable for sandboxing, or less likely to appear as a hazard on the security radar. To make a program suitable for sandboxing, several requirements must be met:
1. The program must run in a separate address space. This can either be a OS process, a software fault isolation (SFI) container, or a SFI container inside an OS process. If an SFI container is used without a separate OS process, additional care must be taken to prevent side-channel attacks, so I do not recommend this solution without significant additional research.
2. All I/O resources (such as file descriptors) must be acquired before processing untrusted input. It must not be possible to use these resources to access additional resources the program should not have access to.
3. Before processing untrusted input, the program must lose the ability to acquire additional I/O resources.
4. The address space (whether an OS process or an SFI container) must not be reused once processing has completed, unless it can be forcibly and verifiably reset to its initial state.
5. If the inputs to the processing were untrusted, the results must also be considered untrusted.
A command-line tool can probably meet all of these requirements but the last one quite easily. For a library, the difficulty of meeting these requirements will depend significantly on the library API. I am not familiar with the GraphicsMagick API and so am not sure how difficult it will be for the GraphicsMagick API to support sandboxing. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
libvips is a demand-driven, horizontally threaded image processing library. A specially crafted SVG input can cause libvips versions 8.14.3 or earlier to segfault when attempting to parse a malformed UTF-8 character. Users should upgrade to libvips version 8.14.4 (or later) when processing untrusted input.
Division-By-Zero vulnerability in Libvips 8.10.5 in the function vipseyepoint, eye.c#L83, and function vipsmaskpoint, mask.c#L85.
imvips2dz in /libvips/libvips/deprecated/imvips2dz.c in libvips before 8.8.2 has an uninitialized variable which may cause the leakage of remote server path or stack address.
vipsforeignloadgifscanimage in foreign/gifload.c in libvips before 8.8.2 tries to access a color map before a DGifGetImageDesc call, leading to a use-after-free.
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
libvips before 8.7.4 generates output images from uninitialized memory locations when processing corrupted input image data because iofuncs/memory.c does not zero out allocated memory. This can result in leaking raw process memory contents through the output image.
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.
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.
It was reported that virt-login-shell, an suid-root program, did not sanitize its environment variables or command-line interface arguments properly. This could allow a local user to overwrite arbitrary files as root and elevate their privileges.
This vulnerability was introduced in libvirt 1.1.2.
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for reporting this issue.
The 'stats' variable in remoteDispatchDomainMemoryStats function was not initialized to NULL, so if some early validation of the RPC call fails, it is possible to jump to the 'cleanup' label and VIRFREE an uninitialized pointer.
A remote user able to issue commands to libvirt daemon could use this flaw to crash libvirtd.
Acknowledgements:
This issue was discovered by Daniel P. Berrange of Red Hat.
A denial of service flaw was found in the way storage pool manager of libvirt, a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes), performed management of socket file descriptors when 'to list all volumes for the particular pool' request was issued (two socket file descriptors were leaked per "list all pool volumes" request). An uprivileged user could use this flaw to cause denial of service (make libvirtd daemon to exhaust / reach the maximum count of open file descriptors, the libvirtd daemon process was allowed to open, possibly preventing other users from use of libvirtd services till the libvirtd daemon was restarted).
Acknowledgements:
Red Hat would like to thank Edoardo Comar of IBM for reporting this issue.
A flaw was found in the way message freeing on connection cleanup was handled under certain error conditions. 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.
Acknowledgements:
This issue was discovered by Tingting Zheng of Red Hat.
Thierry Carrez <thierry> reports:
Pádraig Brady from Red Hat discovered that the fix implemented for CVE-2012-3361 (OSSA-2012-008) was not covering all attack scenarios. By crafting a malicious image with root-readable-only symlinks and requesting a server based on it, an authenticated user could still corrupt arbitrary files (all setups affected) or inject arbitrary files (Essex and later setups with OpenStack API enabled and a libvirt-based hypervisor) on the host filesystem, potentially resulting in full compromise of that compute node.
Regression introduced in commit d6623003 (v0.8.8) - using the wrong sizeof operand meant that security manager private data was overlaying the allowDiskFOrmatProbing member of struct virSecurityManager. This reopens disk probing, which was supposed to be prevented by the solution to CVE-2010-2238.
Upstream patch: https://www.redhat.com/archives/libvir-list/2011-May/msg01935.html
Description of problem: When several libvirtd threads are reporting errors at the same time, the errors can get mixed or corrupted, potentially leading to a libvirtd crash (DoS).
Upstream commit: https://www.redhat.com/archives/libvir-list/2011-March/msg01087.html