CVE-2026-77159: Libvirt: unsafe chown in qemutpmemulatorpreparehost() allows arbitrary file ownership change via symlink
A symlink-following flaw was found in libvirt's qemuTPMEmulatorPrepareHost() function (src/qemu/qemutpm.c). The function uses a path-based chown() to set ownership of the swtpm logfile without verifying that the path is not a symbolic link. Since the log directory is writable by the swtpm user, a local attacker with access to the swtpm account can replace the logfile with a symlink pointing to an arbitrary file. When libvirtd (running as root) starts a QEMU domain with an emulated TPM, it follows the symlink and transfers ownership of the target file to swtpm:swtpm, allowing the attacker to then modify that file.
The upstream fix replaces the path-based chown() with open(ONOFOLLOW) + fchown() on the file descriptor.
External reference: https://gitlab.com/libvirt/libvirt/-/workitems/909
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libvirtto a version that resolves this vulnerability.Patch https://gitlab.com/libvirt/libvirt/-/work_items/909 - Compensating control
Ensure the swtpm logfile path is not writable by the swtpm user (e.g., make the log directory non-writable) to prevent a symlink from being placed there that libvirtd would follow.
Event History
Frequently Asked Questions
Who can exploit this issue?
A local attacker needs access to the swtpm account and must be able to replace the swtpm logfile in its writable log directory with a symbolic link. Remote access alone is not described as sufficient.
What event triggers the unsafe ownership change?
The vulnerable path is triggered when libvirtd, running as root, starts a QEMU domain configured with an emulated TPM. It follows the attacker-controlled symlink and changes ownership of the target file to swtpm:swtpm.
What is the practical impact after exploitation?
The attacker can cause an arbitrary target file to become owned by swtpm:swtpm, then modify that file using the swtpm account. The stated impact is integrity loss; confidentiality and availability impacts are not listed.
What change addresses the flaw?
The upstream fix replaces path-based chown() with opening the file using O_NOFOLLOW and then applying fchown() to the resulting file descriptor. This prevents chown from following a symbolic link at the logfile path.