MOKSHA-2026-0058: Xenstore Quota Exhaustion via VM.xenstore_data

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can exhaust a guest domain's xenstore quota by injecting a large number of vm-data/* keys into VM.xenstore_data. Xenstore enforces a per-domain quota (default 25 MB shared with guest agent data). Keys written to VM.xenstore_data are written to guest xenstore at /local/domain/<domid>/vm-data/ by xenopsd at domain.ml:604-624. When the injected data consumes the guest's quota, the guest's own xenstore operations fail, disrupting PV drivers, network configuration, and guest agent communication. The VM.xenstore_data field has zero map_keys_roles entries and no value length limits.

Vulnerability Description

VM.xenstore_data is a Map(String, String) field writable by vm-admin with zero per-key RBAC. XAPI imposes no limits on the number of keys, key name length, or value length. The only filter is the filtered_xsdata prefix check at domain.ml:164-170 which accepts keys starting with vm-data/ or FIST/.

The exhaustion path:

1. vm-admin writes hundreds of large vm-data/* entries via XAPI:

   VM.add_to_xenstore_data(vm, "vm-data/flood-0001", "<large_string>")
   VM.add_to_xenstore_data(vm, "vm-data/flood-0002", "<large_string>")
   ...
   

2. XAPI stores all entries in the database without size validation (message_forwarding.ml:2092-2099)
3. If the VM is running, xenopsd writes all keys to guest xenstore via set_xsdata at domain.ml:2250-2255
4. On VM boot, all keys are written to guest xenstore at domain.ml:604-624
5. Guest xenstore quota is consumed by injected data
6. Guest's own xenstore operations (PV drivers, network config, guest agent) fail with ENOSPC or equivalent

The guest xenstore quota is shared between all consumers in the domain. Legitimate uses include PV driver configuration, network interface metadata, and guest agent communication. When vm-admin-injected data consumes this quota, the guest loses the ability to function correctly.

Root Causes

1. No size limits. XAPI imposes no limit on the number of keys, key name length, or value length in VM.xenstore_data. The database accepts arbitrarily large maps.

2. Missing RBAC protection. VM.xenstore_data has zero map_keys_roles entries. All key prefixes are writable by vm-admin.

3. Shared quota with guest services. Xenstore uses a per-domain quota that is shared between hypervisor-injected data and guest-generated data. There is no reservation or partitioning mechanism.

4. No quota awareness in XAPI. XAPI does not check whether the injected data will exceed the guest's xenstore quota before writing. The quota is enforced by xenstore itself, after the write attempt.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI codebase)
• XCP-ng - all versions (confirmed on 8.3.0)

Indirectly Affected

• Guest VMs - PV drivers, networking, and guest agent communication fail when xenstore quota is exhausted
• Management tools - guest agent data (IP addresses, OS version, metrics) becomes unavailable
• Monitoring systems - lose visibility into guest state

Exploitation Scenarios

Chaining Analysis

• BOC-1 + XSD-4: With root access via BOC-1 S3, the attacker bulk-injects quota-exhausting data into all VMs, causing pool-wide PV driver and guest agent failures.
• XSD-4 + XSD-1: Quota exhaustion (XSD-4) prevents guest agents from writing legitimate data to xenstore, while XSD-1 (guest agent poisoning) fills the remaining quota with attacker-controlled configuration. The guest agent reads poisoned data because it cannot write its own.

Detection

• Monitor VM.xenstore_data size (total key+value bytes) per VM
• Alert on rapid growth or unusually large VM.xenstore_data maps
• Monitor guest agent health indicators (IP reporting, metrics collection)
• See rule X-04 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit VM.xenstore_data for VMs with unusually large maps
• Remove unexpected vm-data/* entries not required for guest operation
• Monitor guest agent health across the pool

Long-Term Fix

Add size limits. Enforce maximum key count, key name length, and value length at the XAPI layer before writing to the database.

Add quota awareness. Before writing VM.xenstore_data to guest xenstore, check whether the data will exceed the guest's xenstore quota and reject the write if so.

Partition xenstore quota. Reserve a minimum quota for guest-generated xenstore entries separate from hypervisor-injected data.

Upstream patches exist. They are held privately pending coordinated disclosure.

Disclosure

Disclosure:

• Public release: 2026-04-24 08:00 CEST
• CERT/CC notified: 2026-04-23
• MITRE CVE reservation filed: 2026-04-09 (no response as of publication)
• EU CVE registers notified: 2026-04-18 (GCVE/CIRCL, ENISA, DIVD - no response)
• Vendor (Cloud Software Group / Citrix): not contacted pre-publication
• Downstream maintainer (Vates/XCP-ng): contacted 2026-04-23 with conditional patch offer

References

• XAPI source: domain.ml:164-170 (allowed_xsdata_prefixes prefix filter), domain.ml:604-624 (vm-data dir created with rwperm, data written), domain.ml:2250-2255 (live update writes data to guest xenstore), message_forwarding.ml:2092-2099 (zero validation on write), datamodel_vm.ml:2818-2831 (VM.xenstore_data field definition)
• Thematic advisory: disclosure/advisories/xsd-security-advisory.md (XSD-4)
• Investigation: research/investigations/vm-xenstore-data.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.