EDK II - NULL Pointer Dereference in XhcInitializeDeviceSlot
Multiple unchecked allocations lead to NULL pointer dereference in RELEASE builds during USB device slot initialization.
- Advisory
- BYTERAY-2026-0264
- CWE
- CWE-690
- Vendor
- TianoCore
- Product
- EDK II
- Reported
- 2026-06-25
- Disclosure
- 2026-10-29
- Affected
- EDK II at commit 70741a15d9a714323a5598eac47727e60507e22f (master, 2026-06-21); affected code in MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c.
- Credit
- Argus-Systems
Executive Summary
Multiple unchecked allocations lead to NULL pointer dereference in RELEASE builds during USB device slot initialization. At line 2246, UsbHcAllocateMem is called for InputContext with only ASSERT guards before ZeroMem(InputContext, ...) at line 2249 dereferences it. At line 2307, AllocateZeroPool(sizeof(TRANSFER_RING)) for EndpointTransferRing has NO NULL check (not even ASSERT) before the result is stored and passed to CreateTransferRing. This function is called from XhcPollPortStatusChange when a USB device connects.
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:2246 - Function:
XhcInitializeDeviceSlot - Category:
error_handling
Technical Details
Controllability: SEMI_TRUSTED — confidence: high. Physical USB device triggers enumeration; memory pressure causes allocation failures. Both sizes are constant (sizeof (INPUT_CONTEXT), sizeof (TRANSFER_RING)), so the device cannot cause the failure itself.
Data Flow
XhcPollPortStatusChange at line 1840 detects USB connect (physical device). At line 2246, InputContext = UsbHcAllocateMem(...) returns NULL on failure. At line 2247, ASSERT is a no-op in RELEASE. At line 2249, ZeroMem(InputContext, ...) dereferences NULL. Additionally at line 2307, EndpointTransferRing = AllocateZeroPool(sizeof(TRANSFER_RING)) has NO CHECK AT ALL, then at line 2309 CreateTransferRing dereferences NULL.
Affected Callers
XhcPollPortStatusChange
Sanitization / Security Controls
- ASSERT at line 2247 is DEBUG-only (ineffective in RELEASE); line 2307 has no check at all.
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
- Physical access to USB port; RELEASE build; memory pressure.
- Attacker connects any USB device.
- Enumeration triggers under memory pressure.
- Allocations return NULL.
- Dereferences crash firmware.
Impact
Denial of service — firmware crash during USB enumeration.
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.