A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can cause a VIF's network rate limiting to be silently disabled by setting kbps=0 in VIF.qos_algorithm_params. XAPI accepts the zero value without validation and stores it in the database. When the VIF is plugged, xenopsd computes bytes_per_interval = 0, which fails the bounds check at device.ml:850 (bytes_per_interval > 0L), causing the rate limit to be silently dropped. The XAPI database continues to show rate limiting as "configured" while no rate is enforced in xenstore. Administrators and automation tools that check the XAPI database see a false positive - they believe rate limiting is active when it is not.
VIF.qos_algorithm_params is a Map(String, String) field writable by vm-admin with zero per-key RBAC. When VIF.qos_algorithm_type is set to ratelimit, the kbps key specifies the rate limit in kilobits per second.
The code path:
vm-admin sets kbps=0: VIF.add_to_qos_algorithm_params(vif, "kbps", "0")kbps via Int64.of_string at xapi_xenops.ml:795 - zero is accepted(0L, timeslice_us) is passed to xenopsddevice.ml:835-856:timeslice_us defaults to 50000L (50ms) since 0L <= 0Lbytes_per_interval = (0 * 1024 * 50000) / 1000000 = 00 > 0L is false - rate is silently droppedrate key is written to xenstorekbps=0 as the configured rateThis is a defense-in-depth success at the xenopsd layer - the invalid rate is correctly rejected. The vulnerability is the observability gap: XAPI accepts the value without error, stores it in the database, and provides no feedback that the rate limit is not active. The gap between what the database says and what is actually enforced is the security issue.
Missing write-time validation. XAPI accepts kbps=0 without rejecting it. A rate of zero kilobits per second is never a valid rate limit.
Silent rejection at consumer. xenopsd correctly rejects the computed rate but emits only a debug-level log. No error propagates back to the API caller or the management layer.
Database-xenstore state divergence. The XAPI database reflects what was written via the API. Xenstore reflects what was actually applied. When these diverge, monitoring and audit tools that read the XAPI database report a false positive.
Missing RBAC protection. VIF.qos_algorithm_params has zero map_keys_roles entries. Any vm-admin can set or remove rate limits without restriction.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Silent rate limit removal | VIF operates without rate limiting while XAPI shows it as configured | vm-admin, ratelimit QoS type | Confirmed (live host) |
| Compliance evasion | Audit tools report rate limiting active; actual enforcement is absent | vm-admin, compliance monitoring | Source-traced |
| Bandwidth monopolization | VM consumes unbounded bandwidth while appearing rate-limited | vm-admin, shared network | Source-traced |
VIF.qos_algorithm_params:kbps in XAPI database against actual xenstore rate key in VIF backend pathkbps values of zerodisclosure/vendor-detection-guidance.mdVIF.qos_algorithm_params records for kbps=0kbps value that is zero or negativeAdd write-time validation. Reject kbps values of zero and negative numbers at the XAPI API layer. Return an API error to the caller rather than accepting an invalid configuration.
Propagate rejection errors. When xenopsd rejects a rate value, propagate the error back to the XAPI layer so the database can reflect the actual enforcement state.
Add map_keys_roles protection. Restrict the kbps key to _R_POOL_OP so vm-admin cannot unilaterally modify rate limits.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_xenops.ml:781-808 (rate parsing, no range check on kbps), device.ml:835-856 (bytes_per_interval computation and bounds check), device.ml:850 (silent drop on out-of-range), datamodel.ml:1666-1681 (qos field definition, zero map_keys_roles)disclosure/advisories/vqp-security-advisory.md (VQP-2)research/investigations/vif-qos-algorithm-params.mdDiscovered and reported by Jakob Wolffhechel, Moksha.