EDK II - NULL Pointer Dereference in XhcPeiInitSched

Executive Summary

The PEI-phase counterpart of XhcInitSched. Three allocations use ASSERT-only guards: Dcbaa at line 2920, ScratchEntryMap at line 2935 sized by MaxScratchpadBufs from hardware registers, and ScratchEntry at line 2942 with the same pattern. MaxScratchpadBufs is built from two 5-bit fields of HCSPARAMS2 (line 2928, XhciReg.h:127/129), so it is at most 1023 and each pool allocation is at most 8 KB; Dcbaa is sized from the 8-bit MaxSlots field, at most 2 KB. The allocations only fail when PEI memory is already exhausted.

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/Bus/Pci/XhciPei/XhciSched.c:2920
• Function: XhcPeiInitSched
• Category: error_handling

Technical Details

Controllability: SEMI_TRUSTED — confidence: high. MaxScratchpadBufs and MaxSlotsEn come from hardware registers, but their field widths keep the sizes small, so a malicious XHCI controller cannot force the allocations to fail.

Data Flow

At line 2920, Dcbaa = UsbHcAllocateMem(...) with ASSERT-only, then written at line 2983 and used at line 2995. At line 2935, ScratchEntryMap = AllocateZeroPool(sizeof(UINTN) * MaxScratchpadBufs) sized by hardware register value with ASSERT-only. At line 2942, ScratchEntry follows the same pattern; both are indexed in the loop at lines 2962-2977. PEI-phase controller initialization.

Affected Callers

• XhcPeimEntry

Sanitization / Security Controls

• 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. XHCI controller present during PEI-phase boot; RELEASE build; PEI memory exhausted.
2. Controller reports a non-zero MaxScratchpadBufs (at most 1023) via the HcSParams2 hardware register.
3. XhcPeiInitSched allocates Dcbaa at line 2920, ScratchEntryMap at 2935, and ScratchEntry at 2942.
4. Because memory is exhausted, an allocation fails and returns NULL.
5. ASSERT guards compile to no-ops in RELEASE builds; subsequent dereferences crash the firmware.

Impact

Denial of service — firmware crash during PEI XHCI init.

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