MOKSHA-2026-0038: Provisioning Type Manipulation via SR.sm_config allocation

Summary

A pool-operator in XAPI-based hypervisors (XenServer, XCP-ng) can corrupt storage provisioning behavior by modifying or removing the allocation key in SR.sm_config after SR creation. The key controls whether LVHD SRs use thin or thick provisioning. Changing allocation from thin to thick (or removing the key) causes new VDIs to pre-allocate their full logical volume size instead of thin-provisioning. On overcommitted SRs, this causes immediate storage exhaustion with SR_BACKEND_FAILURE_44 errors. Restoring the key does not shrink already-inflated LVs - recovery requires storage migration (export, destroy, recreate, reimport). The sm_config field has zero map_keys_roles entries, and the allocation key is intended to be set once by the SM driver during SR.create but remains writable through the API.

Vulnerability Description

SR.sm_config is a Map(String, String) field writable by pool-operator. The allocation key is set by LVHDSR.create() during SR creation and controls the provisioning strategy for all subsequent VDI operations.

The code path:

1. During SR.create, the SM driver sets sm_config:allocation = "thin" (or "thick")
2. LVHDSR.__init__() reads PROVISIONING_TYPES = ["thin", "thick"] (LVHDSR.py:94)
3. A pool-operator calls SR.remove_from_sm_config(sr, "allocation") or SR.add_to_sm_config(sr, "allocation", "thick")
4. Next VDI creation reads the corrupted allocation value
5. If changed from thin to thick: VDI LVs are created at full logical size instead of minimum allocation
6. Overcommitted SRs immediately fail with space exhaustion

Live-tested results:

• On a thin-provisioned iSCSI SR, removing the allocation key caused the next VDI to pre-allocate the full LV size
• The SR reached capacity during VDI creation, producing SR_BACKEND_FAILURE_44
• Restoring allocation=thin did not shrink the already-inflated LVs
• Recovery required storage migration: export VDIs, destroy SR, recreate, reimport (hours of downtime)

Root Causes

1. Missing field immutability. SR.sm_config is qualifier:RW despite containing keys that should be immutable after driver initialization. The allocation key is set by the SM driver during SR.create but is modifiable by any pool-operator at any time.

2. Missing RBAC protection. SR.sm_config has zero map_keys_roles entries. Every key is writable by pool-operator.

3. No write-time validation. XAPI does not validate allocation against PROVISIONING_TYPES. Any string is accepted, including empty string and non-existent values.

4. Irreversible damage. LVs inflated under thick mode do not shrink when the key is restored. The damage requires storage migration to remediate.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared SM driver codebase)
• XCP-ng - all versions (confirmed on 8.3.0, 18/18 PoC checks PASS)

Indirectly Affected

• All VMs on affected SR - storage exhaustion causes I/O errors for all VMs
• Overcommitted environments - thin provisioning is common in production; corruption breaks the space accounting model

Exploitation Scenarios

Detection

• Monitor SR.sm_config for modifications after SR creation - any change to allocation is suspicious
• Compare SR.sm_config:allocation against expected provisioning type for each SR
• Alert on SR_BACKEND_FAILURE_44 errors (space exhaustion) on thin-provisioned SRs
• See rule S-08 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all SR.sm_config records: verify allocation matches the intended provisioning type
• Take periodic snapshots of SR.sm_config to detect drift
• Monitor SR free space aggressively on thin-provisioned SRs

Long-Term Fix

Enforce sm_config immutability. Once set by the SM driver during SR.create, driver-written keys should not be modifiable via the API. Implement a StaticRO equivalent for driver-set keys in sm_config.

Add map_keys_roles. Protect all driver-written keys (allocation, use_vhd, targetIQN, etc.) at _R_LOCAL_ROOT_ONLY in datamodel.ml.

Validate allocation. At write time, validate the value against PROVISIONING_TYPES (["thin", "thick"]). Reject any other value.

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: datamodel.ml:4949-4953 (SR.sm_config field definition), LVHDSR.py:94 (PROVISIONING_TYPES), LVHDSR.py:205-206 (allocation read during init)
• Thematic advisory: disclosure/advisories/ssmc-security-advisory.md (SSMC-1)
• Investigation: research/investigations/sr-sm-config.md
• PoC evidence: research/smc-1/poc/evidence/smc-1-s8-iscsi-thin-20260214.log, smc-1-s8-iscsi-thick-20260214.log

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.