GPU VulnDB

Database/Kernel, userspace & hypervisor

libvirt swtpm state handling: symlink following lets the swtpm user take ownership of arbitrary files

CVSS 7.8CVE-2026-63622Kernel, userspace & hypervisorcurated

Impact

virFileChownFiles() follows symbolic links when it fixes up ownership of the swtpm state directory. A process already running as the confined swtpm user can plant a symlink there and have the root libvirt daemon chown any file on the host to swtpm, which converts a contained sandbox into write control over root-owned files and from there into host root. This only matters on hypervisor hosts that give guests a virtual TPM, but that is a common configuration for confidential or attested VM offerings, which is precisely where GPU tenants are sold isolation as the product. The precondition is that the attacker already holds the swtpm sandbox, so this is a defence-in-depth failure rather than a first foothold.

Who can reach it

Local on the hypervisor host, and only from a process already executing as the confined swtpm user (typically reached by first compromising the swtpm process serving a guest vTPM). No network access and no libvirt credentials are needed.

What to do

Install the patched libvirt from your distribution (Red Hat ships it in RHSA-2026:64773, RHSA-2026:65515 and RHSA-2026:65516 for the affected RHEL streams) and restart the libvirt daemons. Restarting the modular libvirt daemons does not stop running domains, so this is a daemon restart per host rather than a drain, though the daemons briefly stop accepting management calls. Hosts that do not configure a vTPM for any guest 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.