A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can set VIF.qos_algorithm_params:kbps and timeslice_us to values that cause Int64 overflow in the bytes_per_interval computation at device.ml:835-845. OCaml silently wraps on integer overflow, producing unexpected rate values. xenopsd's subsequent bounds check (0 < bytes_per_interval < 0xffffffff) catches most overflow results and silently drops the rate. In edge cases where the wrapped value falls within the valid range, the applied rate bears no relation to the configured kbps value. The VIF.qos_algorithm_params field has zero map_keys_roles entries.
VIF.qos_algorithm_params is a Map(String, String) field defined at datamodel.ml:1666-1681 via the qos function with zero map_keys_roles entries and _R_VM_ADMIN as the class default write role.
The overflow occurs in the rate computation at device.ml:835-848:
let bytes_per_interval =
((kbytes_per_s ^* 1024L) ^* timeslice_us) ^/ 1000000L
Where ^* is Int64.mul and ^/ is Int64.div. OCaml's Int64.mul performs modular arithmetic on overflow - it silently wraps without raising an exception.
The data flow:
kbps=9223372036854775 and timeslice_us=1000000Int64.of_string at xapi_xenops.ml:795 - no range check(9223372036854775L, 1000000L) forwarded to xenopsd(9223372036854775 * 1024 * 1000000) / 10000009223372036854775 * 1024 overflows Int64(0, 0xffffffff), it is applied as the rateIn most overflow cases, xenopsd's bounds check rejects the result. The concern is the architectural pattern: user-controlled values flow into arithmetic operations without overflow guards, and OCaml's silent wrapping makes the behavior unpredictable.
Missing overflow protection. The bytes_per_interval computation uses Int64.mul without checking for overflow. OCaml silently wraps on overflow.
Missing write-time validation. XAPI accepts any Int64-parseable string for kbps without range checking. Values near Int64 bounds are stored without error.
Missing RBAC protection. VIF.qos_algorithm_params has zero map_keys_roles entries. All keys are writable by vm-admin.
set_qos_algorithm_params RBAC bypass. The set_qos_algorithm_params method replaces the entire map and bypasses map_keys_roles per-key checks.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Overflow producing valid rate | VIF rate-limited at unexpected value, unrelated to configured kbps | vm-admin, VIF with ratelimit QoS | Source-traced |
| Overflow producing out-of-range | Rate silently dropped, VIF operates without rate limit | vm-admin, VIF with ratelimit QoS | Live-tested (rejection confirmed) |
| Observability gap | XAPI DB shows configured kbps, xenstore has different or no rate | vm-admin | Live-tested |
VIF.qos_algorithm_params:kbps in XAPI DB against actual xenstore rate key in VIF backend pathkbps values exceeding link speed or near Int64 boundsdisclosure/vendor-detection-guidance.mdVIF.qos_algorithm_params entries for extreme kbps valuesAdd overflow-safe arithmetic. Check for overflow before the Int64.mul operations in device.ml:848. Reject values where the multiplication would overflow.
Add write-time range validation. Validate kbps at XAPI write time: enforce 0 < kbps <= 100000000 (100 Gbps maximum). Reject values that would cause overflow in the rate computation.
Return error on rejection. When xenopsd rejects a rate value, propagate an error to XAPI rather than silently dropping the rate.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
datamodel.ml:1666-1681 (VIF.qos_algorithm_params field definition), xapi_xenops.ml:781-808 (rate parsing - no range check), device.ml:835-856 (bytes_per_interval computation with Int64.mul overflow, bounds check)disclosure/advisories/vqp-security-advisory.md (VQP-4)research/investigations/vif-qos-algorithm-params.mdDiscovered and reported by Jakob Wolffhechel, Moksha.