A pool-operator in XAPI-based hypervisors (XenServer, XCP-ng) can relax memory ratio bounds for all VMs in the pool by writing extreme values to Pool.other_config:memory-ratio-hvm and Pool.other_config:memory-ratio-pv. These keys define the lower bound ratio where memory-dynamic-min >= ratio * memory-static-max. The default ratio is 0.25. Setting the ratio to 0 or a very low value (e.g., 0.001) allows VMs to be configured with near-zero dynamic minimum memory, causing guest OS instability or crashes pool-wide when the balloon driver aggressively reclaims memory. The keys are consumed as float values at xapi_globs.ml:618-624 with no range validation. The Pool.other_config field has no map_keys_roles entries for infrastructure keys. Live host verification confirmed the keys are present with default values on production systems.
Pool.other_config is a Map(String, String) field defined at datamodel_pool.ml:1764-1773 with _R_POOL_OP as the minimum write role.
The memory ratio keys are defined at xapi_globs.ml:618-624:
let memory_ratio_hvm = "memory-ratio-hvm" (* default: "0.25" *)
let memory_ratio_pv = "memory-ratio-pv" (* default: "0.25" *)
These ratios enforce a lower bound on memory-dynamic-min relative to memory-static-max. When a VM's memory configuration is set, XAPI checks:
memory-dynamic-min >= ratio * memory-static-max
By setting the ratio to 0 or near-zero, an attacker allows VMs to have their dynamic minimum memory set arbitrarily low. The Xen balloon driver then reclaims memory down to this minimum, potentially leaving the guest OS with insufficient memory to operate.
The impact is pool-wide: these are pool-level keys that affect all HVM or PV VMs across every host in the pool.
Missing range validation. The ratio values are consumed as floats with no minimum or maximum bounds. Values of 0, negative numbers, and values greater than 1.0 are all accepted.
Missing RBAC protection. Pool.other_config has map_keys_roles entries only for UI keys (folder, XenCenter.CustomFields.*, EMPTY_FOLDERS). The memory ratio keys are writable by any pool-operator.
Pool-wide blast radius. A single key write affects the memory configuration bounds for every VM of the corresponding type (HVM or PV) across the entire pool.
set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses map_keys_roles per-key checks.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Memory bounds removal | VMs can be configured with near-zero dynamic-min memory | pool-operator, set ratio to 0 | Source-traced |
| Guest OS instability | Balloon driver reclaims memory below safe threshold, guest crashes | pool-operator, ratio relaxed + VM memory adjusted | Modeled |
| Pool-wide memory squeeze | All VMs across pool subject to aggressive memory reclamation | pool-operator | Modeled |
| BOC-1 chain | vm-admin relaxes memory bounds across pool via RBAC collapse | vm-admin, BOC-1 | Source-traced |
Pool.other_config for changes to memory-ratio-hvm and memory-ratio-pvdisclosure/vendor-detection-guidance.mdPool.other_config for unexpected memory-ratio-hvm and memory-ratio-pv valuesAdd range validation. Enforce a minimum (0.01) and maximum (1.0) range for memory ratio values at write time.
Add map_keys_roles protection. Restrict memory-ratio-hvm and memory-ratio-pv to _R_POOL_ADMIN in datamodel_pool.ml.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
datamodel_pool.ml:1764-1773 (Pool.other_config field definition), xapi_globs.ml:618-624 (memory ratio key definitions and defaults)disclosure/advisories/ploc-security-advisory.md (PLOC-7)research/investigations/pool-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.