Hi all, This patch set contains a bundle of fixes for various security flaws discovered, as part of a pro-active hardening effort, in the GRUB2 code recently. The most severe one, i.e. potentially exploitable, has CVE assigned and is listed at the end of this email.
Details of exactly what needs updating will be provided by the respective distros and vendors when updates become available. Full mitigation against CVE will require updated shim with latest SBAT (Secure Boot Advanced Targeting) [1] data provided by distros and vendors. This time UEFI revocation list (dbx) will not be used and revocation of broken artifacts will be done with SBAT only. For information on how to apply the latest SBAT revocations, please see mokutil(1). Vendor shims may explicitly permit known older boot artifacts to boot. Updated GRUB2, shim and other boot artifacts from all the affected vendors will be made available when the embargo lifts or some time thereafter. I am posting all the GRUB2 upstream patches which fix all security bugs found and reported up until now. Affected Linux distros carry or will carry soon one form or another of these patches. Now all the GRUB2 upstream patches are in the GRUB2 git repository [2] too. I would like to thank Maxim Suhanov for responsible disclosure and preparation of patches needed to fix known issues. Michael Chang has been helping with fixing and testing the patches. Thank you! Daniel [1] https://github.com/rhboot/shim/blob/main/SBAT.md https://github.com/rhboot/shim/blob/main/Delivering_Sbat_Revocations.md [2] https://git.savannah.gnu.org/gitweb/?p=grub.git https://git.savannah.gnu.org/git/grub.git ******************************************************************************* CVE-2025-4382: GRUB allows access to encrypted device through CLI once root device is unlocked via TPM CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - 5.9 A flaw was found in systems utilizing LUKS-encrypted disks with GRUB configured for TPM-based auto-decryption. When GRUB is set to automatically decrypt disks using keys stored in the TPM, it reads the decryption key into system memory. If an attacker with physical access can corrupt the underlying filesystem superblock, GRUB will 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. This scenario may allow an attacker with physical access to access the unencrypted data without any further authentication, thereby compromising data confidentiality. Furthermore, the ability to force this state through filesystem corruption also presents a data integrity concern. Reported-by: Maxim Suhanov ******************************************************************************* docs/grub.texi | 32 +++++++++++++++++++++++++++++++- grub-core/commands/minicmd.c | 11 +++++++++++ grub-core/commands/search.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ grub-core/commands/search_wrap.c | 7 ++++++- grub-core/disk/cryptodisk.c | 29 +++++++++++++++++++++++++++++ grub-core/disk/diskfilter.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ grub-core/kern/rescue_reader.c | 2 +- grub-core/normal/main.c | 3 ++- include/grub/cryptodisk.h | 1 + include/grub/search.h | 7 ++++--- 10 files changed, 228 insertions(+), 7 deletions(-) Maxim Suhanov (7): kern/rescue_reader: Block the rescue mode until the CLI authentication commands/search: Introduce the --cryptodisk-only argument disk/diskfilter: Introduce the "cryptocheck" command commands/search: Add the diskfilter support docs: Document available crypto disks checks disk/cryptodisk: Add the "erase secrets" function disk/cryptodisk: Wipe the passphrase from memory Michael Chang (1): cryptocheck: Add --quiet option _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
