Confidential PodVM: host-injected GPT partitions are auto-mounted, swap leaks TEE-encrypted memory

Impact

In OpenShift Sandboxed Containers confidential peer pods, the threat model treats the host and hypervisor as the adversary. A malicious host can add partitions to the guest's virtual disk, and systemd-gpt-auto-generator discovers and mounts them at boot by type GUID without asking. The worst case is an injected swap partition: the guest kernel then pages TEE-encrypted memory out to a block device the host controls, which breaks the confidentiality guarantee that AMD SEV-SNP or Intel TDX is supposed to give. The dm-verity root and the roothash= parameter protect only the root partition. Swap, /home, /var, /srv and /var/tmp are still auto-discovered. Remote attestation measures PCRs 3, 9, 11 and 12 but not PCR 5 (the GPT partition table), so a tampered disk still passes attestation. For anyone selling confidential GPU or CPU workloads on top of these images, the attestation result cannot be relied on while this is open.

Who can reach it

The host or hypervisor operator, or anyone who has compromised the host, with high privileges and the ability to change the guest's virtual disk. This is the adversary confidential computing is built to defend against. The guest does not have to do anything.

What to do

Follow the Red Hat advisory for fixed PodVM images and systemd packages. The record does not give a fixed version. From the description, the exposure comes from the generator shipping unmasked in the RHEL systemd-udev subpackage, from no measured kernel command-line parameter disabling it, and from PCR 5 being left out of attestation. Rebuilt PodVM images will have to be rolled out and confidential pods restarted on them. Re-check attestation policies once the fix is published.

References

Related entries

• Linux kernel (arch/x86/kvm/svm): VMLOAD/VMSAVE executed by an L2 guest and not intercepted by L1 were emulated againstCVE-2026-43133 · Linux kernel (arch/x86/kvm/svm)High
• Linux kernel KVM nSVM: L2 guest can issue hypercalls as if it were L1 when VMMCALL is not interceptedCVE-2026-46076 · Linux kernel KVM nSVM (unintercepted VMMCALL in L2)High
• util-linux nsenter: --join-cgroup leaks a root-opened cgroup.procs fd into the target containerCVE-2026-78408 · util-linux nsenter (--join-cgroup descriptor leak across execve)High
• Linux kernel KVM/arm64: guest-controlled TLBI Range can overflow the hypervisor's range computationCVE-2026-89911 · Linux kernel KVM arm64 (TLBI by Range)High
• Linux kernel RDS (Reliable Datagram Sockets) net/rds/page.c - rds_page_copy_user: Straight local-to-root. RDS - theCVE-2010-3904 · Linux kernel RDS (Reliable Datagram Sockets) net/rds/page.c - rds_page_copy_userHigh
• Linux kernel KVM device assignment IOMMU path virt/kvm/iommu.c - kvm_iommu_map_pages: When an IOMMU mapping failsCVE-2014-3601 · Linux kernel KVM device assignment IOMMU path virt/kvm/iommu.c - kvm_iommu_map_pagesHigh