Bug 2558210 (CVE-2026-121876)

Summary:	CVE-2026-121876 sandboxed-containers: kernel: systemd-gpt-auto-generator: Guest Data Leakage in Confidential Computing (Sandboxed Containers)
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, security-response-team, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the interaction between systemd-gpt-auto-generator and confidential computing guest VM images in OpenShift Sandboxed Containers (confidential peer pods). systemd-gpt-auto-generator automatically discovers and mounts GPT partitions by type GUID at boot with no user confirmation. In the confidential computing threat model, where the host/hypervisor is the adversary, a malicious host can inject partitions into the guest's virtual disk. Most critically, injecting a swap partition causes the guest kernel to page out TEE-encrypted memory to a host-controlled block device, breaking the confidentiality guarantee of the hardware TEE (AMD SEV-SNP, Intel TDX). The PodVM images use a GPT-partitioned disk with dm-verity on the root partition. However, the roothash= kernel parameter only disables root auto-discovery — non-root partitions (swap, /home, /var, /srv, /var/tmp) are still auto-discovered and mounted. The generator is shipped unmasked in the RHEL systemd-udev subpackage, and no kernel command line parameter in the measured UKI addon disables it. Additionally, the PodVM measurement script captures PCRs 3, 9, 11, and 12, but not PCR 5 (GPT partition table), so partition table modifications are not detected by remote attestation.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Deadline:	2026-11-12

Description OSIDB Bzimport 2026-10-21 11:20:05 UTC

A vulnerability was found in the interaction between systemd-gpt-auto-generator and
confidential computing guest VM images in OpenShift Sandboxed Containers (confidential
peer pods). systemd-gpt-auto-generator automatically discovers and mounts GPT
partitions by type GUID at boot with no user confirmation. In the confidential
computing threat model where the host/hypervisor is the adversary, this allows a
malicious host to inject partitions (most critically, a swap partition) into the
guest's virtual disk. When a swap partition is activated, the guest kernel pages out
TEE-encrypted memory to the host-controlled block device, defeating the entire
confidentiality guarantee of the TEE.

The PodVM images use a GPT-partitioned disk with dm-verity on the root partition,
but the roothash= kernel parameter only disables root auto-discovery — swap, /home,
/var, /srv, and /var/tmp partitions are still auto-discovered and mounted. The
systemd-gpt-auto-generator is shipped unmasked in the RHEL systemd-udev subpackage
and no kernel command line parameter in the measured UKI addon disables it.

Attack vectors include:
1. Swap partition injection (Critical) — host attaches swap partition, guest kernel
pages out TEE-encrypted memory to host-readable block device
2. /var or /home mount replacement (High) — host captures data written to these
paths or injects malicious content
3. LUKS auto-unlock key exposure (Medium) — host-provided vTPM may enable key
extraction
4. ESP/XBOOTLDR replacement (Medium) — hostile ESP can inject modified boot
configuration

The PodVM measurement script captures PCRs 3, 9, 11, 12 but NOT PCR 5 (GPT partition
table), so partition table modifications are not detected by remote attestation.

Reported by: Spyros Seimenis, Edgeless Systems (https://redhat.atlassian.net/browse/PSIRTSUPT-25976)