EDK II - NULL Pointer Dereference in FvIsBeingProcessed

Executive Summary

In FvIsBeingProcessed, a KNOWN_HANDLE is allocated with AllocatePool(sizeof(KNOWN_HANDLE)) but only guarded by ASSERT(KnownHandle != NULL) — a no-op in RELEASE builds. Line 1148: KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE dereferences NULL. This function runs inside SMM when the SMM Core dispatcher marks a firmware volume as processed. Its only caller, SmmDriverDispatchHandler, is registered with UnRegister = TRUE (PiSmmCore.c:84) and is unregistered at SMM ready-to-lock (PiSmmCore.c:363-365), so the path only runs during boot-time SMM driver dispatch, before any third-party code can reach SMM.

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:1145
• Function: FvIsBeingProcessed
• Category: error_handling

Technical Details

Controllability: APPLICATION_CONTROLLED — confidence: high. Constant-size allocation in SMM; failure requires SMRAM exhaustion during boot-time SMM driver dispatch, which no untrusted code can cause.

Data Flow

At line 1145, KnownHandle = AllocatePool(sizeof(KNOWN_HANDLE)) returns NULL on failure. At line 1146, ASSERT(KnownHandle != NULL) is a no-op in RELEASE. At line 1148, KnownHandle->Signature = KNOWN_HANDLE_SIGNATURE dereferences NULL in the SMM context. Lines 1149–1150 further dereference the pointer. Called from SmmDriverDispatchHandler (line 1335) for each not-yet-processed firmware volume handle.

Affected Callers

• SmmDriverDispatchHandler

Sanitization / Security Controls

• SMM context; ASSERT — 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. RELEASE build; SMM driver dispatch during boot, before SMM ready-to-lock.
2. SMRAM pool is exhausted (for example by injected allocation failure).
3. FvIsBeingProcessed is called from SmmDriverDispatchHandler.
4. At line 1145, AllocatePool(sizeof(KNOWN_HANDLE)) returns NULL on failure.
5. ASSERT(KnownHandle != NULL) at line 1146 compiles to no-op in RELEASE; KnownHandle->Signature at line 1148 dereferences NULL inside SMM

Impact

Fault inside SMM during boot-time SMM driver dispatch, causing a boot failure. The handler is removed at ready-to-lock, so there is no attacker path to this allocation failure after boot.

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