A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can set VIF.qos_algorithm_params:kbps to an extremely large value (e.g., 999999999) that causes bytes_per_interval to exceed 0xffffffffL during computation in xenopsd. xenopsd correctly rejects the out-of-range value and does not write a rate key to xenstore - but does so silently with only a debug-level log. XAPI continues to show the configured rate limit in the database. The result is an observability gap: administrators and automation tools believe rate limiting is active on the VIF when it is not. The VM operates without network rate limiting while the management plane reports it as enforced.
VIF.qos_algorithm_params is a Map(String, String) field writable by vm-admin. When VIF.qos_algorithm_type is set to ratelimit, XAPI parses the kbps key via Int64.of_string at xapi_xenops.ml:795 with no range validation and forwards the rate tuple to xenopsd.
The code path:
vm-admin sets VIF.qos_algorithm_params:kbps to 999999999kbps via Int64.of_string - accepts any 64-bit signed integer (xapi_xenops.ml:795)(kbps, timeslice_us) rate tuple with no range checkbytes_per_interval = kbps * 1000 / 8 * timeslice_us / 1000000device.ml:850 checks whether bytes_per_interval > 0xffffffffL - the check fails for large kbps valuesrate key to xenstorekbps=999999999The observability gap arises because xenopsd's rejection is invisible to XAPI and to administrators. XAPI does not receive an error callback; the VIF plugs successfully without rate limiting.
Missing write-time validation. XAPI accepts any value for kbps without range validation. Negative, zero, and overflow-inducing values are stored in the database.
Silent consumer-side rejection. xenopsd correctly rejects invalid rates but only emits a debug-level log. XAPI is not notified of the rejection.
State inconsistency. The XAPI database reports rate limiting as configured while the data plane has no rate enforcement. Administrators and automation cannot detect the discrepancy without directly inspecting xenstore.
Missing RBAC protection. VIF.qos_algorithm_params has zero map_keys_roles entries. All keys inherit the vm-admin class default.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Rate limit bypass via large kbps | VIF operates without rate limiting while XAPI shows rate configured | vm-admin, VIF with qos_algorithm_type=ratelimit | Confirmed (live-tested) |
| Bandwidth starvation | Unthrottled VM consumes shared network capacity, starving co-hosted VMs | vm-admin, shared network with rate-limited VIFs | Modeled |
| Compliance violation | Network QoS policies appear enforced when they are not | vm-admin, compliance-sensitive deployment | Modeled |
VIF.qos_algorithm_params:kbps in XAPI DB against actual xenstore rate key in the VIF backend pathkbps values that are negative, zero, or exceed link speeddisclosure/vendor-detection-guidance.mdqos_algorithm_type=ratelimit but no xenstore rate key existsAdd write-time validation. Validate kbps at XAPI write time: reject negative values, zero, and values exceeding reasonable network capacity (e.g., 100 Gbps). Return an error to the caller.
Propagate rejection to XAPI. When xenopsd rejects a rate value, report the failure back to XAPI so the database reflects actual enforcement state.
Range-validate timeslice_us. Enforce reasonable bounds on the scheduling timeslice parameter.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_xenops.ml:781-808 (rate parsing, no range validation), device.ml:835-856 (xenopsd bounds check and silent rejection), datamodel.ml:1666-1681 (qos field definition)disclosure/advisories/vqp-security-advisory.md (VQP-1)research/investigations/vif-qos-algorithm-params.mdDiscovered and reported by Jakob Wolffhechel, Moksha.