MOKSHA-2026-0061: I/O Scheduling Downgrade to Idle Class via VBD.qos_algorithm_params

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can downgrade a target VM's I/O scheduling class to idle by setting sched=idle in VBD.qos_algorithm_params. The idle scheduling class causes the Linux kernel to service the VBD's kernel threads only when no other I/O is pending on the host. Under any host I/O load, the target VM experiences severe I/O starvation - disk operations become effectively unresponsive. The VBD.qos_algorithm_params field has zero map_keys_roles entries, and QoS changes take effect immediately via hot-apply without VBD replug. This is a targeted denial-of-service that requires only vm-admin access to the target VM's VBD.

Vulnerability Description

VBD.qos_algorithm_params is a Map(String, String) field writable by vm-admin with zero per-key RBAC. When VBD.qos_algorithm_type is set to ionice, the sched key determines the I/O scheduling class for VBD kernel threads.

The code path:

1. vm-admin identifies target VBD UUIDs via xe vbd-list
2. Sets VBD.qos_algorithm_type to ionice and qos_algorithm_params:sched to idle
3. XAPI parses the sched key at xapi_xenops.ml:604-617:

   | "idle" -> Idle
   

4. Ionice.to_class_param at ionice.ml:28 maps Idle to class 3:

   | Idle -> (3, to_param Lowest)
   

5. xenopsd invokes ionice -c3 -n7 -p<kthread_pid> via execve
6. The kernel sets the VBD kernel threads to idle scheduling class

The idle scheduling class (class 3) is the lowest priority in the Linux I/O scheduler. Processes in this class are served only when no other I/O requests from any class (real-time or best-effort) are pending. On a host with any concurrent I/O activity - which is the norm in multi-VM environments - the target VM's disk I/O stalls indefinitely.

QoS changes are applied hot via the Needs_set_qos action request mechanism (xenops_server_xen.ml:4003-4017). When the current ionice settings differ from the target, xenopsd re-invokes ionice on running kernel threads without requiring VBD replug or VM reboot.

Root Causes

1. Missing RBAC protection. VBD.qos_algorithm_params has zero map_keys_roles entries. The sched key inherits the class default _R_VM_ADMIN, allowing any vm-admin to set any scheduling class.

2. No validation of scheduling class appropriateness. XAPI accepts idle as a valid scheduling class without checking whether it is appropriate for the target VM. A vm-admin managing multiple VMs can set a destructive scheduling class on VMs they do not own.

3. Hot apply without authorization check. QoS changes take effect immediately on running VBDs. There is no confirmation step, no secondary authorization check, and no rate limiting on scheduling class changes.

4. Insufficient logging. Scheduling class changes produce only debug-level log messages. No security alert is generated when a VBD's scheduling class is changed to idle.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared xenopsd codebase)
• XCP-ng - all versions (confirmed on 8.3.0, source trace and live verification)

Indirectly Affected

• Target VMs - experience severe I/O starvation when idle class is applied to their VBDs
• Storage infrastructure - iSCSI/NFS protocol timeouts from idle-class VBDs may appear as storage array issues rather than QoS manipulation

Exploitation Scenarios

Chaining Analysis

• BQP-3 + BQP-1: The idle-class downgrade (BQP-3) combined with real-time class abuse (BQP-1) creates a compound I/O scheduling attack - the attacker claims real-time class for their own VBDs while degrading target VMs to idle class, maximizing the performance differential.
• BOC-1 + BQP-3: With root access via BOC-1 S3, the attacker sets idle class on all VBDs in the pool except their own, causing persistent pool-wide I/O degradation. The attacker can also modify the XAPI database directly to ensure idle-class settings survive VBD replug and VM reboot.

Detection

• Monitor VBD.qos_algorithm_params for sched=idle on any VBD
• Alert on ionice class 3 assignments in dom0
• Monitor for I/O latency anomalies affecting specific VMs while co-located VMs perform normally
• See rule B-03 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VBD.qos_algorithm_params records for sched=idle values
• Monitor dom0 ionice invocations for class 3 assignments
• Restrict vm-admin delegated access to trusted administrators only

Long-Term Fix

Add map_keys_roles protection. Restrict the sched key to _R_POOL_OP or _R_POOL_ADMIN. I/O scheduling class selection is a host-level resource allocation decision that should not be delegated to tenant administrators.

Restrict idle class. Either remove the idle class option entirely from the parser, or require an elevated role (_R_POOL_ADMIN) to set it. There is no legitimate use case for a delegated administrator to downgrade another VM's I/O scheduling to idle.

Add security-level logging. Log all scheduling class changes at security level, not debug level. Include the session, role, source VBD, and target scheduling class.

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: xapi_xenops.ml:604-617 (sched parser accepts idle class), ionice.ml:17-40 (Idle mapped to class 3), ionice.ml:85-91 (argument formatting), xenops_server_xen.ml:3907-3932 (ionice invocation via execve), xenops_server_xen.ml:4003-4017 (hot-apply QoS change detection), datamodel.ml:1666-1681 (qos field definition, zero map_keys_roles)
• Thematic advisory: disclosure/advisories/bqp-security-advisory.md (BQP-3)
• Investigation: research/investigations/vbd-qos-algorithm-params.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.