EDK II - NULL Pointer Dereference in XenStoreJoin
In XenStoreJoin, Buf = AllocatePool(BufSize) is guarded only by ASSERT(Buf != NULL) — a no-op in RELEASE builds.
- Advisory
- BYTERAY-2026-0258
- 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 OvmfPkg/XenBusDxe/XenStore.c.
- Credit
- Argus-Systems
Executive Summary
In XenStoreJoin, Buf = AllocatePool(BufSize) is guarded only by ASSERT(Buf != NULL) — a no-op in RELEASE builds. Lines 299/301: AsciiSPrint(Buf, BufSize, ...) dereferences NULL. While the allocation is constant-size (based on string lengths), the complete absence of a NULL check in RELEASE means any allocation failure results in a NULL dereference.
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 (
OvmfPkg) - Affected commit:
70741a15d9a714323a5598eac47727e60507e22f(master, 2026-06-21). The code is present on that commit and later revisions that have not changed it. - Location:
OvmfPkg/XenBusDxe/XenStore.c:295 - Function:
XenStoreJoin - Category:
error_handling
Technical Details
Controllability: SYSTEM_CONTROLLED — confidence: high. String-length-based allocation; failure primarily requires memory exhaustion.
Data Flow
At line 294, BufSize = AsciiStrLen(DirectoryPath) + AsciiStrLen(Node) + 2 from string lengths. At line 295, Buf = AllocatePool(BufSize) with ASSERT-only at 296 — no-op in RELEASE. At line 299, AsciiSPrint(Buf, BufSize, "%a", DirectoryPath) dereferences NULL. Called from XenStoreRegisterWatch and other XenStore functions.
Affected Callers
XenStoreRegisterWatch(line 1424)XenStoreListDirectory(line 1217)XenStoreRead(line 1274)XenStoreWrite(line 1297)XenStoreRemove(line 1320)
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
- Memory exhaustion during XenStore path operations; RELEASE build.
XenStoreJoinis called fromXenStoreRegisterWatchor other XenStore functions.- At line 295,
AllocatePool(BufSize)returns NULL on failure. ASSERT(Buf != NULL)at line 296 compiles to no-op in RELEASE builds.AsciiSPrint(Buf, BufSize, ...)at line 299 dereferences NULL, crashing the firmware
Impact
Denial of service — firmware crash during XenStore operations.
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.