EDK II - NULL Pointer Dereference in CreateTransferRing

Executive Summary

In CreateTransferRing, UsbHcAllocateMem (which returns NULL on failure) is called, but only an ASSERT(Buf != NULL) guards the result. ASSERT compiles to a no-op in RELEASE builds. The subsequent ZeroMem(Buf, sizeof(TRB_TEMPLATE) * TrbNum) at line 911 dereferences Buf unconditionally, causing a NULL dereference if the allocation failed. This function is called during USB device enumeration from XhcInitializeDeviceSlot, which is invoked from XhcPollPortStatusChange when a physical USB device is connected. The allocation size is a constant (TR_RING_TRB_NUMBER or CMD_RING_TRB_NUMBER TRBs), and slot teardown frees the transfer rings and device contexts (XhciSched.c:2704-2732, 64-bit variant :2817-2845), so a USB device can trigger the call but cannot make the allocation fail; failure requires memory already being 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/XhciDxe/XhciSched.c:908
• Function: CreateTransferRing
• Category: error_handling

Technical Details

Controllability: SEMI_TRUSTED — confidence: high. A physical USB device triggers the call, but not the allocation failure; exploitation requires memory exhaustion from another cause.

Data Flow

XhcPollPortStatusChange at line 1840 detects a USB device connect (physical device input). XhcInitializeDeviceSlot at line 2309 calls CreateTransferRing. At line 908, Buf = UsbHcAllocateMem(...) returns NULL on failure. At line 909, ASSERT(Buf != NULL) is a no-op in RELEASE. At line 911, ZeroMem(Buf, ...) dereferences NULL in RELEASE builds. TrbNum is a constant, and the rings are freed when a slot is disabled, so repeated enumerations do not accumulate allocations in the USB HC memory pool.

Affected Callers

• XhcInitSched (line 612)
• XhcInitializeDeviceSlot (line 2309)
• XhcInitializeDeviceSlot64 (line 2535)
• XhcInitializeEndpointContext (lines 2997, 3048), reached from XhcSetConfigCmd
• XhcInitializeEndpointContext64 (lines 3173, 3224), reached from XhcSetConfigCmd64

Sanitization / Security Controls

• ASSERT is DEBUG-only, compiles to no-op in RELEASE builds — not an effective control.

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; USB HC memory pool exhausted (for example by injected allocation failure).
2. A USB device is connected and enumerated.
3. XhcInitializeDeviceSlot (or the endpoint setup during XhcSetConfigCmd) calls CreateTransferRing.
4. UsbHcAllocateMem returns NULL; ASSERT is no-op.
5. ZeroMem dereferences NULL.

Impact

Denial of service — firmware crash during USB enumeration, only when memory is already exhausted. A USB device cannot cause the allocation failure itself.

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