EDK II - NULL Pointer Dereference in XenStoreProcessMessage

Executive Summary

In XenStoreProcessMessage, a XENSTORE_MESSAGE is allocated with AllocateZeroPool(sizeof(XENSTORE_MESSAGE)) without checking for NULL. The immediately following line dereferences it via Message->Signature = XENSTORE_MESSAGE_SIGNATURE. While the allocation is constant-size (lower probability of failure than the variable-size Body allocation at line 635), the complete absence of a NULL check means any allocation failure results in a NULL dereference. This function processes host-initiated xenstore messages on the event-channel poll path.

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:626
• Function: XenStoreProcessMessage
• Category: error_handling

Technical Details

Controllability: SYSTEM_CONTROLLED — confidence: high. Constant-size allocation; failure requires pool exhaustion, not directly attacker-controlled input.

Data Flow

At line 626, Message = AllocateZeroPool(sizeof(XENSTORE_MESSAGE)) is a constant-size allocation with no NULL check. At line 627, Message->Signature = XENSTORE_MESSAGE_SIGNATURE immediately dereferences the result. This is reached when reading xenstore messages via XenStoreReadReply at line 762 and XenStoreWaitWatch at line 986. Flooding the shared ring with messages does not exhaust the pool by itself: replies are consumed by XenStoreReadReply, and watch events for unregistered tokens are freed at lines 671-672; only watch events for registered tokens are queued on xs.WatchEvents. The Xen host is also trusted by the guest firmware (XenBusDxe is only built in OvmfPkg/OvmfXen.dsc).

Affected Callers

• XenStoreReadReply
• XenStoreWaitWatch

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 pool exhaustion in the guest firmware.
2. Host sends a XenStore message (reply or watch event).
3. Guest processes it, allocating a XENSTORE_MESSAGE.
4. Pool exhausted; AllocateZeroPool returns NULL.
5. Message->Signature dereferences NULL.

Impact

Denial of service — guest firmware crash; requires sustained memory pressure.

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