MOKSHA-2026-0081: I/O Polling Parameter Manipulation via VBD.other_config polling-duration

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can set the polling-duration and related polling keys (polling-idle-threshold) in VBD.other_config to extreme values within the partially validated range. While in_range validation exists in xenopsd, the accepted range still includes values that alter I/O polling behavior, leading to suboptimal polling configuration and performance degradation on affected VBDs. The VBD.other_config field has zero map_keys_roles entries, leaving all infrastructure keys writable by vm-admin.

Vulnerability Description

VBD.other_config is a Map(String, String) field defined in datamodel.ml with zero map_keys_roles entries - the only other_config field in the audit with absolutely no per-key RBAC protection.

The polling-duration and polling-idle-threshold keys flow from XAPI to xenopsd as extra backend keys:

vm-admin writes VBD.other_config:polling-duration = VALUE
    |
    v
XAPI stores to database (zero write-time validation)
    |
    v
xapi_xenops.ml:663 reads polling-duration from other_config
    |
    v
extra_backend_keys passed to xenopsd
    |
    v
xenopsd writes to xenstore backend path
    |
    v
blkback driver reads polling parameters from xenstore

At xapi_xenops.ml:663, the polling-duration value is read from VBD.other_config and included in extra_backend_keys that are forwarded to xenopsd. Similarly, polling-idle-threshold is read at xapi_xenops.ml:671. xenopsd applies partial validation via in_range bounds checking, accepting values from 0 to max_int. Values within this range are written to the VBD's xenstore backend path and consumed by the blkback kernel driver to configure I/O polling behavior.

The issue is that extreme values within the accepted range (e.g., polling-duration=2147483647) produce suboptimal polling configurations that degrade VBD I/O performance without triggering any validation rejection.

Root Causes

1. Missing RBAC protection. VBD.other_config has zero map_keys_roles entries in datamodel.ml. The polling-duration key is writable by vm-admin via add_to_other_config.

2. Insufficient range validation. While in_range bounds checking exists in xenopsd, the accepted range (0 to max_int) is too broad. Values at the extremes of the range produce valid but suboptimal polling configurations.

3. No resource impact assessment. xenopsd applies the polling parameters without evaluating whether the values are reasonable for the underlying storage device.

4. set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses map_keys_roles per-key checks.

Affected Systems

Directly Affected

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

Indirectly Affected

• VMs using affected VBDs - I/O performance degradation from suboptimal polling configuration
• Co-hosted VMs - extreme polling parameters on one VBD may affect host-level I/O scheduling

Exploitation Scenarios

Chaining Analysis

• BOC-1 + BOC-3: BOC-1 does not lower the RBAC barrier (already vm-admin). With BOC-1 root access, an attacker could modify polling parameters across all VBDs in the pool via direct database manipulation, turning a single-VBD performance impact into pool-wide degradation.
• SMC-1: No interaction. Polling parameters do not touch storage protocol traffic or sm-config values.
• The in_range validation limits exploitability. The impact is performance degradation, not a privilege escalation or data compromise.

Detection

• Monitor VBD.other_config for changes to polling-duration and polling-idle-threshold keys
• Alert on extreme values (e.g., values exceeding 10000 or set to 0)
• Compare configured polling parameters against expected values for the storage device type
• See rule X-05 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VBD.other_config entries for unexpected polling-duration or polling-idle-threshold values
• Monitor VBD I/O performance metrics for anomalies
• Restrict XAPI API access to trusted networks

Long-Term Fix

Add map_keys_roles protection. Restrict polling-duration and polling-idle-threshold to _R_POOL_ADMIN in datamodel.ml. I/O polling configuration is a host-level resource management decision that should not be writable by delegated VM administrators.

Tighten range validation. Replace the broad (0, max_int) range with device-appropriate bounds (e.g., (0, 10000) for polling-duration in microseconds).

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

• Related MOKSHA IDs: MOKSHA-2026-0001 (BOC-1), MOKSHA-2026-0007 (BOC-2)
• XAPI source: datamodel.ml (VBD.other_config field definition - zero map_keys_roles), xapi_xenops.ml:663 (polling-duration read), xapi_xenops.ml:671 (polling-idle-threshold read)
• Thematic advisory: disclosure/advisories/boc-1-security-advisory.md (V5)
• Investigation: research/investigations/vbd-other-config.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.