MOKSHA-2026-0080: I/O Scheduler Sysfs Injection via SR.other_config scheduler

Summary

A pool-operator in XAPI-based hypervisors (XenServer, XCP-ng) can write an arbitrary string to the kernel's I/O scheduler sysfs interface by setting the scheduler key in SR.other_config. The SM driver reads this value at SR.py:203-224 (block_setscheduler) and passes it directly to util.set_scheduler, which writes it to /sys/block/<dev>/queue/scheduler without any XAPI-side validation. The kernel itself validates the value - only registered scheduler names are accepted - limiting direct exploitation. The concern is the architectural pattern: user-controlled data from an XAPI map field flows directly to a kernel control interface with zero intermediate validation. The SR.other_config field has no map_keys_roles entries for infrastructure keys.

Vulnerability Description

SR.other_config is a Map(String, String) field defined at datamodel.ml:4930-4935 with _R_POOL_OP as the minimum write role.

The data flow from XAPI to kernel sysfs:

pool-operator writes SR.other_config:scheduler = VALUE
    |
    v
XAPI stores to database (zero validation)
    |
    v
SR driver operation (attach/scan/etc.)
    |
    v
SR.block_setscheduler(dev) at SR.py:203-224
    reads other_config["scheduler"]
    if sched not in self.scheds: scheds = [sched]   # attacker value
    |
    v
util.set_scheduler(realdev, scheds) at util.py:1156-1178
    |
    v
set_scheduler_sysfs_node("/sys/block/DEV", scheds)
    open("/sys/block/DEV/queue/scheduler", "w")
    file.write("%s\n" % sched)   # attacker value written to kernel sysfs

The block_setscheduler method reads the scheduler value from SR.other_config and attempts to set it as the I/O scheduler for the SR's block devices. If the value is not in the list of known schedulers (self.scheds), it is used directly as the scheduler name.

The kernel's sysfs handler for /sys/block/*/queue/scheduler validates the incoming value against registered schedulers. Unknown scheduler names are silently rejected. This kernel-side validation prevents arbitrary code execution through this path.

Valid scheduler names that an attacker could set to alter I/O behavior:

• none / noop - no-op scheduler, disables I/O ordering
• deadline / mq-deadline - deadline-based scheduling
• cfq - completely fair queuing
• bfq - budget fair queuing
• kyber - latency-oriented scheduler

Switching an SR's block devices to a suboptimal scheduler can degrade storage performance for all VMs using that SR.

Root Causes

1. Missing write-time validation. XAPI stores the value without checking it against known scheduler names. The validation happens only at the kernel sysfs write, well after the attacker-controlled value has traversed multiple components.

2. Missing RBAC protection. SR.other_config has map_keys_roles entries only for UI keys (folder, XenCenter.CustomFields.*). The scheduler key is writable by any pool-operator.

3. Direct kernel interface write. User-controlled data from an API-level map field flows to a kernel sysfs control file without intermediate sanitization. Even though the kernel validates the value, this architectural pattern is unsafe: the XAPI layer should validate before reaching the kernel interface.

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 SM driver codebase)
• XCP-ng - all versions (confirmed via source trace)

Indirectly Affected

• VMs using the affected SR - I/O performance changes when scheduler is switched
• Storage-intensive workloads - suboptimal scheduler selection degrades throughput or latency

Exploitation Scenarios

Chaining Analysis

• SOC-1 + SOC-2 (MOKSHA-2026-0036): Scheduler manipulation (SOC-1) combined with LVM configuration injection (SOC-2) creates compound storage infrastructure manipulation. The I/O scheduler affects how LVM operations are queued.
• BOC-1 + SOC-1: BOC-1 collapses the pool-operator barrier. A vm-admin changes the I/O scheduler on all block-device-backed SRs, degrading storage performance pool-wide.
• The kernel-side validation limits the exploitability of this finding. The primary concern is the architectural pattern rather than a confirmed high-impact attack vector.

Detection

• Monitor SR.other_config for changes to the scheduler key
• Alert on scheduler changes outside of planned maintenance windows
• Audit /sys/block/*/queue/scheduler on all hosts for unexpected scheduler values
• See rule S-01 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all SR.other_config entries for unexpected scheduler values
• Monitor block device scheduler settings via sysfs
• Restrict XAPI API access to trusted networks

Long-Term Fix

Add write-time validation. Validate the scheduler value against a whitelist of known Linux I/O schedulers (none, noop, deadline, cfq, bfq, mq-deadline, kyber) at XAPI write time. Reject unknown values.

Add map_keys_roles protection. Restrict the scheduler key to _R_POOL_ADMIN in datamodel.ml.

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-0036 (SOC-2), MOKSHA-2026-0037 (SOC-3), MOKSHA-2026-0073 (SOC-4), MOKSHA-2026-0074 (SOC-5)
• XAPI source: datamodel.ml:4930-4935 (SR.other_config field definition), SR.py:203-224 (block_setscheduler - reads scheduler key), util.py:1156-1178 (set_scheduler_sysfs_node - writes to /sys/block/*/queue/scheduler)
• Thematic advisory: disclosure/advisories/soc-security-advisory.md (SOC-1)
• Investigation: research/investigations/sr-other-config.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.