Description

A local attacker with control over GRUB's configuration can bypass lockdown restrictions when booting with Secure Boot and load an unsigned GRUB module, while GRUB continues to report lockdown is enabled. The vulnerability is caused by insufficient validation of the MMIO base address passed to the GRUB serial command. GRUB does not validate that the base address corresponds to a UART device, rather than being an arbitrary memory address. This allows an attacker to trick GRUB into writing non-arbitrary data at an attacker-controlled address, including resetting the grub_file_verifiers list in a way that disables the subsequent verification of loaded modules.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-10-02T11:17:39.727Z",
  "pubdate": "2026-10-02T11:17:39.727Z",
  "executiveSummary": "This vulnerability involves an improper validation flaw in the GRUB bootloader, specifically concerning the handling of MMIO (Memory-Mapped I/O) base addresses provided to the serial command.\nA local attacker with the ability to modify GRUB configuration files can exploit this vulnerability to bypass Secure Boot lockdown restrictions, facilitating the execution of arbitrary, unsigned GRUB modules.\nThe flaw stems from the failure of the serial command to verify that the provided memory address correctly identifies a UART device, instead allowing access to arbitrary system memory addresses.\nBy manipulating memory contents, an attacker can corrupt the grub_file_verifiers list, effectively disabling signature verification mechanisms for subsequent modules.\nThis bypasses critical security integrity checks while the system incorrectly reports that Secure Boot lockdown remains active, leading to potential system compromise and persistence mechanisms.\nThe vulnerability requires local access and the ability to modify GRUB configuration, making it a critical threat to system integrity in environments where boot configurations are not strictly protected via platform security features.",
  "technicalDetails": "The vulnerability resides in the GRUB serial interface implementation, which fails to enforce strict bounds and device-type validation for MMIO base addresses provided via the serial configuration command.\nIn a secure boot scenario, GRUB is expected to enforce lockdown by ensuring that all modules loaded into memory are cryptographically verified against trusted keys. This process relies on a chain of trust involving the grub_file_verifiers list, which tracks active security verification hooks.\nThe exploit flow begins with the attacker modifying the GRUB configuration file (e.g., grub.cfg). By supplying a crafted MMIO address to the serial command that points to a specific memory region rather than a legitimate UART device, the attacker gains a primitive that allows writing data to that memory location.\nThe primary exploitation objective is the corruption of the grub_file_verifiers list. By carefully selecting the MMIO address and payload data, the attacker can overwrite the contents of this list, effectively clearing the registered verifiers. Because the verification mechanism relies on these hooks to intercept and validate module loading, clearing them effectively disables the integrity check for any subsequent modules loaded by GRUB.\nOnce the verifiers are neutralized, GRUB continues execution under the guise of an active lockdown state, as the internal status flags are not immediately updated to reflect the integrity failure. The attacker can then load malicious, unsigned GRUB modules, which are accepted as valid despite the presence of Secure Boot.\nThis attack vector allows for the subversion of the boot process, potentially enabling the injection of malicious code into the operating system kernel or the installation of persistent boot-level threats that evade standard kernel-level security audits. Since the compromise occurs within the bootloader stage, the malicious modules operate with full system privileges and can intercept hardware-level initialization or bypass platform security features before the primary kernel gains control."
}