Red Hat libvirt symlink flaw can transfer arbitrary file ownership

A symlink-following flaw was found in libvirt's qemuTPMEmulatorPrepareHost() function. The function uses a path-based chown() on the swtpm logfile without checking for symbolic links. A local attacker with access to the swtpm account can replace the logfile with a symlink, causing libvirtd (running as root) to transfer ownership of an arbitrary file to the swtpm user.

• Red Hat Enterprise Linux 10: the libvirt component is marked Fix deferred by Red Hat. The normalized record identifies the default status as affected; no fixed release or erratum is provided. • Red Hat Enterprise Linux 9: the libvirt component is marked Fix deferred. No fixed release or erratum is provided. • Red Hat Enterprise Linux 8: the virt:rhel/libvirt component is marked Fix deferred. No fixed release or erratum is provided. • Red Hat Enterprise Linux 6: Red Hat marks the product Not affected because the vulnerable code is not present. • Red Hat Enterprise Linux 7: Red Hat marks the product Out of support scope. Red Hat explains that products in this state contain the impacted component but were not fully analyzed and should be assumed affected.

Red Hat also notes that, unless explicitly stated otherwise, previous versions in any minor update stream of a listed product should be assumed vulnerable. A fix-deferred status does not guarantee that a fix will be released.

The flaw is in libvirt's qemuTPMEmulatorPrepareHost() function, which handles the swtpm logfile in src/qemu/qemu_tpm.c. The vulnerable code uses a path-based chown() without verifying that the target is not a symbolic link. Because the log directory is writable by the swtpm account, a local attacker with access to that account can replace the logfile with a symlink to another file.

When libvirtd runs as root and starts a QEMU domain with an emulated TPM, the path-based operation can follow the symlink and transfer ownership of the target to swtpm:swtpm. The swtpm account can then modify the target file, creating a risk of unauthorized changes to data or configuration. The upstream fix replaces the path-based operation with an open using O_NOFOLLOW followed by fchown() on the file descriptor. Which downstream package builds contain that fix must be verified against the vendor's package state.

The flaw is locally reachable, requires low-level access to the swtpm account, and does not require user interaction. Exploitation also requires the ability to replace the logfile with a symbolic link and for libvirtd to start a QEMU domain that uses an emulated TPM.

The supplied record marks public exploit status as true, but it does not provide exploit code, a specific exploit sequence, or evidence of a named exploitation campaign. No campaign, victim, or specific breach is identified in the available evidence.

The flaw allows root-running libvirtd to transfer ownership of an attacker-selected target file to swtpm:swtpm when the logfile has been replaced with a symlink. The swtpm account can then modify that file, making unauthorized data or configuration changes the primary technical consequence.

The documented impact remains within the affected system and does not automatically grant the attacker root privileges. Exploitation requires local access to swtpm, the ability to replace the logfile, and a libvirtd operation that starts a QEMU domain with an emulated TPM. The available evidence does not establish direct confidentiality loss or denial of service, although changing a security-sensitive target file could have significant operational or security consequences.

• The flaw can undermine the integrity of a file that the swtpm account should not own, including files protected by libvirt or the operating system. • It can weaken the separation between the confined swtpm account and root-owned files. • Practical impact depends on the file selected by the symlink, the permissions available to swtpm after ownership changes, emulated TPM configuration, and SELinux enforcement. • The available evidence does not establish direct data disclosure or service disruption as an outcome of the flaw.

1. Keep SELinux enforcing on Red Hat Enterprise Linux and do not set it to permissive mode or disable it. Red Hat states that the swtpm_t domain restricts the creation of symlinks to arbitrary file types and reduces the scope of an ownership change.
2. Monitor for and apply a Red Hat update when a fix is released for the relevant deployment branch. Red Hat currently marks the affected libvirt components on Red Hat Enterprise Linux 10 and Red Hat Enterprise Linux 9, and virt:rhel/libvirt on Red Hat Enterprise Linux 8, as Fix deferred; no exact fixed release is available.
3. If building libvirt from source, use code that incorporates the upstream change from path-based chown() to opening the file with O_NOFOLLOW and calling fchown() on the file descriptor. Verify that the deployed build contains this change.
4. Review existing swtpm logfiles and handle unexpected symbolic links through a safe file-administration process. Removing an individual symlink should not be treated as a replacement for the code fix or SELinux mitigation.
5. Assess Red Hat Enterprise Linux 7 separately because its out-of-support-scope status does not provide an assured fix. Consider removing or disabling the affected component where operationally appropriate.

1. Inventory systems running libvirt on the affected Red Hat Enterprise Linux branches and record the installed package build rather than relying only on an upstream version string.
2. Review domain configurations for emulated TPM use and identify the corresponding swtpm logfile locations.
3. Check those logfiles with a symlink-safe file inspection method and look for unexpected symbolic links or ownership.
4. Verify that SELinux is enforcing and that swtpm is confined to the swtpm_t domain. This reduces impact but does not demonstrate that the vulnerable code has been fixed.
5. If audit telemetry is already enabled, review unexpected ownership changes involving files associated with swtpm or libvirtd. This is precautionary monitoring, not a documented IOC or a source-backed event signature.