Bug 2513066 (CVE-2026-63623)

Summary: CVE-2026-63623 libvirt: Information disclosure via world-readable storage volume images during clone/convert
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in libvirt. During storage volume clone or convert operations, newly created volume images were temporarily world-readable. This was caused by the `qemu-img` utility running with overly permissive file creation settings, allowing any local user to read the full guest disk contents. This vulnerability could lead to sensitive information disclosure from guest virtual machines.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2513493    
Bug Blocks:    

Description OSIDB Bzimport 2026-08-10 09:51:42 UTC 
A file permission vulnerability was found in libvirt's storage volume clone/convert path in src/storage/storage_util.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