EDK II - NULL Pointer Dereference in SmmAddToDriverList

Executive Summary

The SMM driver dispatcher allocates an EFI_SMM_DRIVER_ENTRY with AllocateZeroPool but only guards it with ASSERT(DriverEntry != NULL), which compiles to a no-op in RELEASE. The next line dereferences it via DriverEntry->Signature. The allocation is constant-size, so failure requires SMRAM pool exhaustion. While the SMM context makes this security-relevant (a fault inside SMM at ring -2), realistic exploitation requires an attacker capable of exhausting SMRAM, which is non-trivial.

This advisory is one of a set reported to VulnCheck on 2026-06-25 for coordinated disclosure to the EDK II maintainers. After several follow-ups over the following months no response was received. 126 days after the initial report, ByteRay is publishing the findings in good faith so that affected integrators can assess and remediate them. All findings were identified against EDK II commit 70741a15d9a714323a5598eac47727e60507e22f (master, 2026-06-21).

Affected Products and Versions

• Vendor: TianoCore
• Product: EDK II (MdeModulePkg)
• Affected commit: 70741a15d9a714323a5598eac47727e60507e22f (master, 2026-06-21). The code is present on that commit and later revisions that have not changed it.
• Location: MdeModulePkg/Core/PiSmmCore/Dispatcher.c:1235
• Function: SmmAddToDriverList
• Category: error_handling

Technical Details

Controllability: APPLICATION_CONTROLLED — confidence: high. Constant-size allocation inside SMM; failure requires SMRAM pool exhaustion which implies the attacker already has high privilege.

Data Flow

At line 1235, DriverEntry = AllocateZeroPool(sizeof(EFI_SMM_DRIVER_ENTRY)) is a constant-size allocation that returns NULL on failure. At line 1236, ASSERT(DriverEntry != NULL) is a no-op in RELEASE. At line 1238, DriverEntry->Signature = EFI_SMM_DRIVER_ENTRY_SIGNATURE dereferences NULL in the SMM context (ring -2). Called from SmmDriverDispatchHandler during SMM driver dispatch.

Affected Callers

• SmmDriverDispatchHandler (Dispatcher.c:1423), while walking firmware volumes for SMM drivers during boot

Sanitization / Security Controls

• SMM execution context (ring -2); ASSERT is DEBUG-only.

Reachability and Preconditions

Attacker position and trust level for this issue are stated in the Controllability line and Data Flow above, and the concrete trigger is in Reproduction below.

Exploitability: Low
Realism: Low

Reproduction

1. SMRAM pool exhaustion; RELEASE build; SMM driver dispatch in progress.
2. SMRAM pool is exhausted when the dispatcher reaches a new SMM driver.
3. SmmAddToDriverList called from SmmDriverDispatchHandler (line 1423).
4. AllocateZeroPool returns NULL; ASSERT no-op.
5. DriverEntry->Signature dereferences NULL inside SMM.

Impact

Denial of service: a NULL pointer write inside SMM (ring -2) that hangs or crashes the boot. The allocation is constant-size and happens during boot-time dispatch of SMM drivers from firmware volumes, so no external input influences it and it does not give privilege escalation.

Remediation and Mitigation

As of commit 70741a15d9a714323a5598eac47727e60507e22f this issue is unfixed upstream and no CVE has been assigned. Check the allocation result for NULL before dereferencing it and fail the operation cleanly when allocation fails. The specific control that is absent or ineffective is identified in the Sanitization / Security Controls list under Technical Details.

Timeline

• 2026-06-25 - Reported to VulnCheck for coordinated disclosure to the TianoCore / EDK II security team.
• 2026-07 to 2026-10 - Several follow-ups sent; no response received.
• 2026-10-29 - Public disclosure in good faith, 126 days after the initial report.

Credits

Discovered and reported by Argus-Systems.

References

• EDK II source (TianoCore)
• Affected file at the referenced commit