CVE-2025-4382 Overview
A security flaw has been identified in systems utilizing LUKS-encrypted disks with GRUB configured for TPM-based auto-decryption. When GRUB is configured to automatically decrypt disks using keys stored in the TPM (Trusted Platform Module), it reads the decryption key into system memory during the boot process. An attacker with physical access to the system can exploit this vulnerability by corrupting the underlying filesystem superblock, causing GRUB to fail to locate a valid filesystem and enter rescue mode. At this point, the disk is already decrypted, and the decryption key remains loaded in system memory, allowing unauthorized access to unencrypted data.
Critical Impact
Physical attackers can bypass full disk encryption by forcing GRUB into rescue mode, gaining access to decrypted data without any further authentication. This compromises both data confidentiality and integrity.
Affected Products
- Systems utilizing LUKS-encrypted disks with GRUB TPM-based auto-decryption
- GNU GRUB bootloader with TPM auto-unlock configuration
- Linux distributions with GRUB TPM2 integration enabled
Discovery Timeline
- 2025-05-09 - CVE CVE-2025-4382 published to NVD
- 2025-07-29 - Last updated in NVD database
Technical Details for CVE-2025-4382
Vulnerability Analysis
This vulnerability is classified as CWE-306 (Missing Authentication for Critical Function). The flaw exists in the interaction between GRUB's TPM-based auto-decryption mechanism and its error handling when filesystem corruption is encountered.
When GRUB is configured for TPM-based auto-decryption, the bootloader retrieves the disk encryption key from the TPM during the early boot process. This key is loaded into system memory to perform the decryption operation. Under normal circumstances, GRUB would proceed to mount the decrypted filesystem and continue the boot sequence with appropriate authentication controls.
However, if the filesystem superblock is corrupted—either through intentional manipulation by an attacker with physical access or other means—GRUB fails to locate a valid filesystem structure. Instead of clearing sensitive key material from memory and halting, GRUB enters rescue mode with the decryption key still present in system memory and the disk already in a decrypted state.
This creates a window of opportunity where an attacker with physical access can interact with the rescue mode shell to access decrypted data without needing to provide any authentication credentials, effectively bypassing the security guarantees that full disk encryption is designed to provide.
Root Cause
The root cause is the Missing Authentication for Critical Function (CWE-306). GRUB's rescue mode does not enforce authentication or properly handle the scenario where disk decryption has occurred but filesystem mounting has failed. The design assumes that if the TPM releases the key and decryption succeeds, the system will proceed normally through authenticated boot stages. The rescue mode fallback path was not designed with the security implications of this intermediate state in mind, leaving decrypted data accessible without authentication when filesystem corruption forces this error condition.
Attack Vector
The attack requires physical access to the target system. An attacker would need to:
- Gain physical access to a system with LUKS encryption and GRUB TPM auto-decryption enabled
- Corrupt the filesystem superblock on the encrypted disk (potentially by manipulating the storage device or modifying disk sectors)
- Reboot the system, causing GRUB to successfully decrypt the disk via TPM but fail to mount the corrupted filesystem
- Interact with the GRUB rescue mode shell to access the now-decrypted disk contents
The attack exploits the gap between successful TPM-based decryption and failed filesystem mounting, where no additional authentication is required to access the decrypted data.
Detection Methods for CVE-2025-4382
Indicators of Compromise
- Unexpected filesystem corruption or superblock damage on LUKS-encrypted volumes
- System logs indicating GRUB rescue mode entries without administrator intervention
- Evidence of physical tampering with the system chassis or storage devices
- Anomalous boot patterns or repeated boot failures on TPM-enabled systems
Detection Strategies
- Implement hardware tamper detection mechanisms to alert on physical access attempts
- Monitor system boot logs for unexpected GRUB rescue mode entries
- Configure BIOS/UEFI to log boot events and alert on deviations from normal boot sequences
- Use measured boot with PCR attestation to detect unexpected boot states
Monitoring Recommendations
- Enable comprehensive boot logging at the firmware and bootloader levels
- Implement physical security monitoring for servers and workstations with sensitive data
- Configure alerting for boot failures or rescue mode entries in centralized logging systems
- Regularly audit TPM and Secure Boot configuration integrity
How to Mitigate CVE-2025-4382
Immediate Actions Required
- Review systems configured with GRUB TPM-based auto-decryption for exposure to this vulnerability
- Implement physical security controls to restrict unauthorized access to affected systems
- Consider disabling TPM auto-unlock for systems in environments with elevated physical access risks
- Monitor vendor advisories for patched GRUB versions and apply updates when available
Patch Information
A patch has been developed for GNU GRUB addressing this vulnerability. The fix modifies the rescue mode behavior in grub-core/kern/rescue_reader.c to properly handle the scenario where disk decryption has occurred but filesystem mounting fails. Organizations should monitor the Red Hat CVE Advisory and Red Hat Bug Report for distribution-specific patches. The GNU GRUB Code Diff shows the technical changes made to address this issue.
Workarounds
- Disable TPM auto-unlock and require manual passphrase entry for disk decryption on sensitive systems
- Implement BIOS/UEFI passwords and enable chassis intrusion detection where available
- Use Secure Boot in conjunction with measured boot to establish a trusted boot chain
- Apply physical security measures such as locked server rooms and tamper-evident seals on system cases
# Example: Disable TPM auto-unlock and configure manual passphrase
# Remove TPM-based keyslot from LUKS volume
cryptsetup luksRemoveKey /dev/sdX --key-slot <tpm-slot-number>
# Verify remaining keyslots require manual authentication
cryptsetup luksDump /dev/sdX
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
