A set of patches has been released to address 6 vulnerabilities in the GRUB2 bootloader, most of which lead to use-after-free memory access. The identified issues could potentially be exploited to bypass the UEFI Secure Boot verification mechanism. The status of vulnerability mitigations in distributions can be evaluated on the following pages: Debian, Ubuntu, SUSE, RHEL, Arch, and Fedora. To address the issues in GRUB2, simply updating the package is not enough; it is also necessary to generate new internal digital signatures and update installers, bootloaders, kernel packages, fwupd firmware, and the shim layer.
Identified vulnerabilities:
- CVE-2025-61661 — an out-of-bounds write in the function grub_usb_get_string(), which can be exploited when processing strings in UTF-8 and UTF-16 encoding sent during the connection of USB devices. The issue is caused by the fact that the buffer was allocated based on the string size specified in the first message from the USB device, while the size during encoding conversion was calculated based on subsequent read operations from the USB device. Accordingly, a modified USB device can be used for the attack, initially returning a lower size value.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — failure to clean up command handlers 'normal', 'normal_exit', 'net_set_vlan', and 'gettext' when unloading the 'normal', 'net', and 'gettext' modules, creating conditions for use-after-free memory access if the marked commands are executed after the corresponding modules are unloaded. Similar vulnerabilities were also found for the commands 'functional_test' and 'all_functional_test', but they have not been assigned CVE identifiers, as these commands are part of a test library and should not be included in production builds.
- CVE-2025-54771 — a bug in counting references to 'fs' structures in the function grub_file_close(), leading to use-after-free memory access.
In most Linux distributions, a small layer called shim, signed by Microsoft, is used for verified boot in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, allowing distribution developers to avoid signing every kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 can lead to the execution of arbitrary code during the stage after the shim verification but before the operating system loads, thus compromising the trust chain while Secure Boot is active and gaining full control over the boot process, such as loading another OS, modifying operating system components, and bypassing Lockdown protection.
To block vulnerabilities without revoking the digital signature, distributions can use the SBAT (UEFI Secure Boot Advanced Targeting) mechanism, which is supported for GRUB2, shim, and fwupd in most popular Linux distributions. SBAT was developed in collaboration with Microsoft and involves adding additional metadata to the executable files of UEFI components, including information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can be separately included in lists of allowed or disallowed components for UEFI Secure Boot.
SBAT allows blocking the use of digital signatures for individual version numbers of components without the need for revoking keys for Secure Boot. Blocking vulnerabilities through SBAT does not require using the UEFI revocation list (dbx) and is performed at the level of replacing the internal key for forming signatures and updating GRUB2, shim, and other boot artifacts supplied by distributions. Prior to the implementation of SBAT, updating the revocation list of certificates (dbx, UEFI Revocation List) was a prerequisite for fully blocking vulnerabilities, as an attacker, regardless of the operating system used, could compromise UEFI Secure Boot using a boot medium with an old vulnerable version of GRUB2, certified with a digital signature.
Source: opennet.ru
