EDK II - NULL Pointer Dereference in XenStoreVSPrint

Executive Summary

In XenStoreVSPrint, Buf = AllocateZeroPool(BufSize) has NO NULL CHECK before it is passed to AsciiVSPrint(Buf, BufSize, FormatString, Marker) at line 1383 and to XenStoreWrite at line 1384. BufSize comes from SPrintLengthAsciiFormat over format strings and arguments supplied by firmware drivers. In a RELEASE build AsciiVSPrint (BasePrintLib) rejects the NULL buffer and returns 0 (PrintLibInternal.c:591), so the dereference happens in XenStoreWrite, where AsciiStrLen(Str) (XenStore.c:1302) reads through NULL.

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:1382
• Function: XenStoreVSPrint
• Category: error_handling

Technical Details

Controllability: SYSTEM_CONTROLLED — confidence: high. Format strings and arguments come from firmware drivers (e.g. XenBus.c:369 writes a numeric state); failure requires memory exhaustion.

Data Flow

At line 1380, BufSize = SPrintLengthAsciiFormat(FormatString, Marker2) + 1 from format string processing. At line 1382, Buf = AllocateZeroPool(BufSize) has NO NULL CHECK. At line 1383, AsciiVSPrint(Buf, BufSize, FormatString, Marker) asserts in DEBUG builds and returns 0 in RELEASE builds. At line 1384, XenStoreWrite calls AsciiStrLen(Str) on the NULL buffer (line 1302), which dereferences NULL. Called from XenStoreSPrint (line 1404) and the protocol wrapper XenBusXenStoreSPrint (line 1576).

Affected Callers

• XenStoreSPrint
• XenBusXenStoreSPrint

Sanitization / Security Controls

• None.

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. Memory exhaustion during XenStore formatted write (RELEASE build).
2. XenStoreVSPrint is called from XenStoreSPrint.
3. At line 1382, AllocateZeroPool(BufSize) returns NULL on failure.
4. At line 1383, AsciiVSPrint(Buf, BufSize, FormatString, Marker) returns 0 without writing (RELEASE build).
5. At line 1384, XenStoreWrite(Transaction, DirectoryPath, Node, Buf) dereferences NULL in AsciiStrLen(Str) at line 1302.

Impact

Denial of service — firmware crash during XenStore write.

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