GRUB2 TPM auto-unlock: forced rescue mode leaves the LUKS volume decrypted with the key still in memory

Impact

On nodes that use GRUB to auto-unlock LUKS volumes with a TPM-sealed key, corrupting the filesystem superblock makes GRUB fail to find a valid filesystem and drop to the rescue shell. By that point the volume is already decrypted and the key is resident in memory, so the rescue prompt gives read access to data that encryption-at-rest was supposed to protect, with no further authentication. This is the scenario colocated GPU fleets buy full-disk encryption for: machines sitting in a cage you do not physically control, where a hands-on visit should not equal a data breach. The record also flags the forced-corruption path itself as an integrity concern.

Who can reach it

An attacker with physical access to the machine or its console who can corrupt the filesystem superblock and then interact with the GRUB rescue prompt. No operating system credentials are needed.

What to do

Update the grub2 packages for your distribution (Red Hat tracks it for RHEL 7 through 10 and OpenShift Container Platform 4; the record does not name fixed versions, and the upstream fix is the rescue_reader.c change at commit c448f511e74cb7c776b314fcb7943f98d3f22b6d). Rolling it out means regenerating the boot configuration and rebooting each affected node, so schedule it with other reboot-class work. Independent of the patch, treat TPM auto-unlock without a second factor as a physical-security decision: if the node lives in space you do not control, requiring a passphrase or network-bound unlock removes this class of attack entirely.

References