URGENT Patch: GRUB2 Flaws Allow Secure Boot Bypass via Use-After-Free Exploits
An updated patch set for the GRUB2 bootloader has been released publicly, addressing six vulnerabilities at once, most of which stem from accessing memory after it has been freed. Such flaws could potentially allow attackers to bypass the UEFI Secure Boot mechanism by interfering with the trusted boot chain before the operating system is launched. The developers emphasize that updating the package alone is insufficient: all signed elements of the boot chain must be rebuilt — installers, bootloaders, fwupd firmware, the shim layer, and kernel packages.
Researchers have provided detailed descriptions of each identified flaw. The most critical is considered to be CVE-2025-61661, related to the handling of USB device string descriptors encoded in UTF-8 and UTF-16. The issue arises from a discrepancy between the string length reported by a device in its initial response and the amount of data actually used during character-set conversion. A modified USB device could deliberately declare a shorter string length, resulting in writes beyond the allocated memory boundary.
Another group of vulnerabilities — CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, and CVE-2025-61662 — stems from the fact that handlers for certain commands remain in memory even after the corresponding modules are unloaded. Affected commands include normal, normal_exit, net_set_vlan, and gettext, used by the normal, net, and gettext modules. Executing these commands after unloading the modules leads to references to memory regions that have already been freed. Similar issues were discovered in the testing commands functional_test and all_functional_test, though no CVE identifiers were assigned because they belong solely to a testing library not intended for release builds.
CVE-2025-54771 is highlighted separately — a flaw in reference counting for filesystem (fs) structures within grub_file_close(), which likewise results in a use-after-free scenario when a file descriptor is closed.
The severity of these vulnerabilities is tied to the nature of trusted boot processes in modern Linux distributions. Most systems rely on the shim layer signed with Microsoft’s key. Shim validates GRUB2, after which control is passed to the bootloader that launches the kernel. This architecture spares developers from needing Microsoft signatures for every bootloader or kernel update. However, if an attacker manages to execute code after shim verification but before system startup, they can alter the boot image, insert malicious components, or circumvent Lockdown mode.
To block vulnerable versions without revoking existing signatures, the SBAT mechanism — Secure Boot Advanced Targeting — is used. SBAT support is implemented in GRUB2, shim, and fwupd across all major distributions. The mechanism embeds metadata into UEFI components, including information about the vendor, product, component, and version. Signed metadata enables selective invalidation of specific builds without modifying Secure Boot’s global keys.
Before SBAT, blocking required updating the UEFI revoked certificates list (dbx). This was necessary because an attacker could boot from an older medium containing a vulnerable yet signed GRUB2 version, thereby bypassing the trusted boot process. SBAT eliminates this dependency by allowing precise, version-level blocking of individual components.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
