GPU VulnDB

Database/Kernel, userspace & hypervisor

libvirt: symlink-following chown on the swtpm logfile hands arbitrary file ownership to the swtpm user

CVSS 5.5CVE-2026-77159Kernel, userspace & hypervisorcurated

Impact

libvirtd runs as root and chowns the swtpm logfile by path without checking for symlinks. A local attacker who already controls the swtpm account can point that path at any file on the host and have libvirtd transfer its ownership to swtpm, which is a stepping stone to further privilege escalation on the hypervisor. On a GPU host running VMs with passed-through accelerators, the hypervisor is the trust boundary between tenant VMs and the fabric, so any root-mediated file operation that a lower-privileged service account can redirect is worth closing. Exploitation requires prior control of the swtpm account, which limits this to chained attacks rather than a direct tenant-to-root jump.

Who can reach it

Local, authenticated: an attacker who already has code execution as the swtpm service account on the virtualization host. Not reachable from a guest or from the network on its own.

What to do

Apply the libvirt update from your distribution when it ships (Red Hat tracks this across RHEL 6 through 10; check the vendor link for the fixed build for your release). Applying it means restarting libvirtd, which does not require stopping running guests but does interrupt management operations briefly - a daemon restart rather than a node drain. Until a package is available, no mitigation is named in the advisory beyond restricting access to the swtpm account and hosts that do not use emulated TPM are not exposed.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.