GRUB2 CVE-2025-61664: Local UAF From Unregistered normal_exit After Module Unload

A newly assigned CVE — CVE-2025-61664 — exposes a robustness flaw in the GRUB2 bootloader’s normal module: the command handler for normal_exit is not unregistered when the module is unloaded, leaving a dangling command pointer that can be invoked later and produce a kernel-mode use-after-free (UAF). The bug is not a remote wormhole; it’s a lifecycle mistake that creates a local, availability- and integrity-oriented attack primitive. Distributors and security trackers published the entry on 18 November 2025, and vendor advisories classify the issue as Medium (CVSS 3.1 base score 4.9), with the attack vector limited to local or otherwise privileged execution contexts that can call GRUB commands after module unload.

Background / Overview​

GRUB2 (the GRand Unified Bootloader, version 2) is the canonical bootloader across Linux distributions and many embedded firmware stacks. It is modular: commands and subsystems can be loaded and unloaded as modules, including the normal module that implements the normal boot flow and associated commands such as normal_exit. A correct module unload must unregister any command handlers or callbacks that reference module-owned memory; failing to do so leaves a time-of-use-after-free window if something later invokes the stale handler. CVE-2025-61664 is exactly such a lifecycle error: the normal_exit command remains registered after the normal module unloads. If the command is executed while its module’s data has been freed, the bootloader will dereference freed memory, producing a UAF that can crash the boot process or — in theory and under precise conditions — be turned into a more serious memory-corruption primitive. This CVE was recorded in public vulnerability repositories and picked up by major distribution trackers shortly after disclosure. Vendor pages and independent trackers uniformly echo the root cause and the impacted component: the normal module’s missing unregister call for the normal_exit command. Several vendors and security aggregators published advisories or tracker entries mapping the CVE into distribution packages and indicating which builds remain vulnerable.

---

What the bug actually is — technical anatomy​

The lifecycle mistake​

The normal module registers the normal_exit command during module load. When the module is later unloaded, the code frees module-owned structures (the command object, its callbacks, and related data). The bug arises because the code path that handles module unload does not call the unregister function for the command — the command remains registered with its name and a function pointer that now points at freed memory. If a later operation invokes the command (for example, by name from a script or an external controller that still believes the command exists), GRUB will execute a stale function pointer that references freed memory — the canonical use-after-free.

Typical consequence: availability and potential memory corruption​

Most public technical summaries emphasize that the immediately reproducible outcome is a crash, hang, or other availability failure — the boot process will hit invalid memory and panic, or at minimum behave unpredictably. Use-after-free in low-level boot code can also be more dangerous in theory: if an attacker can precisely control heap layout and invocation timing, UAFs sometimes escalate into memory-corruption primitives that yield information disclosure or code execution. However, for this GRUB2 bug the common and practical threat is denial-of-service at boot time or corruption of boot-related state. Public trackers and distribution advisories classify the impact predominantly as availability and low confidentiality/integrity impact unless chained with other vulnerabilities.

Preconditions and realistic exploit model​

The Microsoft Security Response Center’s guidance for similar lifecycle bugs clarifies an important point: successful exploitation typically depends on conditions beyond an attacker’s control (timing, heap state, presence of commands, and the attacker’s ability to invoke GRUB commands at the exact time after module unload). That means an exploit is not a “click-and-own” remote attack; an attacker will usually need local access, pre-positioned logic, or to manipulate the environment to induce the precise sequence. The MSRC wording used for related lifecycle CVEs — noting that success depends on environment knowledge, target preparation, or network path injection — applies here as well.
In short: the attack vector is local or host-accessible; attack complexity is moderate-to-high; and the exploitability depends on preconditions that are non-trivial to arrange at scale. Multiple public trackers assign Attack Vector: Local (AV:L) and Attack Complexity: High.

---

Affected products and distribution mapping​

Major distribution trackers and vendor advisories list GRUB2 as affected when the shipped package contains the unpatched normal module code. At disclosure, Debian’s security tracker mapped vulnerable and fixed package versions and indicated ongoing work to integrate backports; Ubuntu’s security page lists the CVE with publication metadata and severity rating. SUSE, Red Hat, and other vendors mirrored the CVE into their tracking systems and (depending on the vendor release and backport policy) issued updates in their stable streams. Administrators must not assume that a particular kernel or grub2 package version number implies a fix — vendors backport differently and version numbers alone can be misleading. Always consult your vendor/security tracker and package changelogs. Representative tracker behavior:

• Debian’s security tracker included CVE-2025-61664 and mapped which grub2 source packages and releases remain vulnerable or have fixes.
• Ubuntu published the CVE entry and classified it Medium with CVSS 3.1 score 4.9.
• Aggregators such as OpenCVE and Snyk reflected the same description and noted that a fix was pushed to the upstream repository, though distribution packaging and publication timing vary.

---

Exploitability, attack scenarios, and what to worry about​

Who can realistically exploit this?​

• Local attackers who can run commands or scripts on the host before reboot; for example, an unprivileged user who can influence GRUB command invocation from the running OS or an attacker able to modify boot scripts or the GRUB configuration that may call commands during a later boot.
• Administrators or management systems that push GRUB modules/commands dynamically in embedded fleets where modules may be unloaded and later invoked.
• Attackers who can physically access a machine and interact with the GRUB prompt during boot (less likely to scale but trivial to perform on a single compromised device).

The common theme is local influence — remote, unauthenticated exploitation without pre-existing access is not the realistic threat model for this CVE. Public advisories explicitly set the attack vector to local and note the need for notable preconditions.

Is there a public proof-of-concept or evidence of active exploitation?​

As of the published advisories and aggregated trackers around disclosure (18–19 November 2025), there was no authoritative public proof-of-concept demonstrating remote exploitation in the wild. Multiple vulnerability databases set the exploitation metric to “none” or “no” and list the EPSS (exploit prediction) as extremely low; sources caution that while the primitive is useful to attackers with local access, it’s not a trivial remote RCE vector. That absence of public PoC does not mean the risk is zero; it means that, at disclosure, there was no public working exploit widely shared. Treat claims of in-the-wild exploitation as unverifiable unless accompanied by incident telemetry or vendor confirmation.

Practical worst-case scenarios​

1. A misconfigured or intentionally permissive management plane for a fleet of appliances issues GRUB commands while modules are being updated; a race induces UAF that bricks or reboots a device at scale.
2. In multi-tenant embedded appliances or devices where local tenants can upload boot scripts or images, a hostile tenant could trigger normal_exit after module unload to cause persistent DoS.
3. An attacker with a partial foothold (e.g., unprivileged shell) arranges a timing and memory layout that upgrades the UAF into a more powerful memory corruption chain — plausible but significantly more difficult and not demonstrated in public artifacts.

---

Vendor response and remediation status​

Upstream GRUB maintainers merged a fix that ensures the normal_exit command is unregistered during module unload, removing the stale-pointer window. Distributors began mapping the upstream commit into their package updates and security advisories. The upstream fix is small and surgical — it clears or nulls the pointer or calls the unregister helper during module teardown — which eases backporting and reduces regression risk. Multiple trackers note that the change is low-risk and straightforward to include in stable builds. However, package-level remediation timelines vary:

• Debian’s tracker enumerates which grub2 packages and releases are vulnerable and which versions contain fixes. Administrators should consult the tracker entry for their release and install the vendor-provided package that lists the CVE or the associated upstream commit in the changelog.
• Ubuntu’s security page lists the publication date and severity and links the advisory that identifies fixed packages for supported releases.
• Aggregators such as OpenCVE and Snyk mirrored the fix status and the upstream commit references while noting that the EPSS/exploit probability is low.

---

Recommended actions for administrators (practical checklist)​

1. Inventory GRUB2 versions across your estate.
   • On Debian/Ubuntu: dpkg -l grub-common grub2*; check apt changelogs.
   • On RHEL/Fedora/SUSE: rpm -q grub2; consult vendor errata.
   • For appliances or firmware images: extract the image and check the GRUB binaries and module list.
2. Consult your distribution/security tracker for precise package mapping.
   • Install the vendor-supplied update that explicitly references CVE-2025-61664 or the upstream commit ID in the package changelog. Do not rely only on kernel/grub version numbers; verify the changelog entry.
3. Apply updates in a controlled maintenance window and reboot.
   • Because GRUB is bootloader-level code, updates commonly require a reboot to complete. Test updates in a staging environment where possible.
4. For custom or embedded GRUB builds:
   • Pull the upstream patch and rebuild GRUB images; ensure that your build process unregisters commands on module unload.
   • Re-generate and re-flash GRUB images into appliances or firmware objects.
5. For production images: avoid shipping test-only commands.
   • Upstream commentary observed that some test commands (for example, functional_test and all_functional_test) exhibit similar missing-unregister behavior and should not be included in production images. Audit your GRUB images and strip test libraries or commands from production builds.
6. Detect and triage incidents.
   • Monitor boot logs and serial console output for OOPS, crashes, or unexplained boot failures after GRUB updates or module unload events.
   • Preserve logs and core dumps from affected hosts for forensic analysis.
7. If immediate patching is impossible:
   • Restrict local access to systems where untrusted users could invoke GRUB commands.
   • Harden management interfaces that can issue GRUB commands during runtime or image deployment.

---

Why this matters — strengths and risks of the upstream response​

Strengths

• The upstream fix is small, surgical, and low-risk: it un-registers the command during module teardown rather than rearchitecting module lifecycle. This makes backporting and distribution packaging straightforward and reduces regression risk.
• The vulnerability is well described by multiple independent trackers and vendor advisories, giving operators clear mapping guidance to packages and fixes. Cross-referencing Debian and Ubuntu trackers yields consistent descriptions and mitigations.
• Public scoring and commentary place the issue in the correct operational perspective: local attack vector, availability-focused impact, and moderate exploit complexity — enabling pragmatic prioritization of patching windows.

Potential risks and caveats

• Long‑tail / embedded devices and vendor kernels: appliances, OEM images, and devices with vendor-customized GRUB builds may not receive timely backports. Those devices can remain exposed indefinitely if vendors do not ship updates or if images are neglected. Operators with such fleets must proactively rebuild or request patches from vendors.
• Attack chaining: although the primary impact is availability, kernel-level UAFs can be chained with other primitives in highly controlled environments. For blue teams, treat UAFs seriously and prioritize patches in multi-tenant or high-value systems.
• False sense of completeness: distributors vary in how they represent fixes in changelogs. A running version number may not reveal whether the upstream commit was included in your specific kernel/GRUB binary. Confirm presence of the fix by verifying the package changelog or the vendor advisory instead of inferring from version alone.

---

Detection and hunting guidance​

Focus detection on boot-time telemetry and GRUB logs:

• Collect serial console logs and centralize boot logs; GRUB crashes often surface on console or in firmware watchdog traces.
• Watch for repeated boot failures, kernel oops after handoff from GRUB, or unexpected fallbacks to rescue shells.
• For embedded fleets, monitor device provisioning logs and any automated boot-time command execution that could invoke normal_exit.
• Preserve evidence: serial console captures and boot-time core dumps (where applicable) provide the best forensic data for a GRUB-level failure.

Indicators to hunt for:

• Logs that show command invocation after module unload or exceptions within GRUB’s normal module.
• Reproducible boot failures tied to certain management operations (module updates, image swaps, post-update boot scripts).

---

Communicating to managers and operations​

• Categorize CVE-2025-61664 as a medium-severity availability bug that requires patching but does not warrant the same emergency response as a confirmed remote RCE.
• For cloud or multi-tenant hosts, raise priority: any attacker with local or guest footprint could weaponize a persistent crash primitive to amplify denial-of-service across the infrastructure.
• For single-tenant desktops or tightly controlled servers, schedule updates in the next routine maintenance window but do not delay indefinitely.
• For appliances and vendor-locked devices, engage the vendor or plan a timeline to re-image or replace vulnerable units if a vendor fix isn’t forthcoming.

---

Conclusion​

CVE-2025-61664 is a textbook lifecycle bug: a missing unregister call for the normal_exit command in GRUB2’s normal module created a use-after-free window that can be invoked after module unload. The practical risk is denial-of-service at boot time and, in tightly controlled exploit chains, potential escalation to memory corruption — but the realistic attack model requires local access and a set of conditions that are non-trivial to reproduce. Upstream maintainers issued a small, targeted fix that distributors are backporting into their GRUB packages; administrators should prioritize installing vendor updates, verifying package changelogs, and hardening GRUB images (removing test commands from production builds) to eliminate the stale-command window. Cross‑checking vendor trackers (Debian, Ubuntu) and public aggregators confirms the core technical description and the remedial course of action; until updates are installed, treat multi-tenant hosts and appliance fleets as higher priority for mitigation.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center