A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can set an arbitrary MTU value (0 through 65535) on any VIF by writing the mtu key in VIF.other_config. The value is parsed by int_of_string at xapi_xenops.ml:773 with no range validation and applied via ip link set. Extreme MTU values (0, 65535) cause network disruption including packet fragmentation, dropped frames, and connectivity failures for the affected VM and potentially for co-located VMs on the same bridge. The VIF.other_config field has zero map_keys_roles entries.
VIF.other_config is a Map(String, String) field writable by vm-admin with zero per-key RBAC via map_keys_roles. The mtu key is consumed at the XAPI level during VIF translation to the xenopsd domain.
The code path:
vm-admin sets an extreme MTU value: VIF.add_to_other_config(vif, "mtu", "65535")xapi_xenops.ml:773 using int_of_stringip link set mtu <value>An MTU of 0 causes the interface to reject all frames. An MTU of 65535 causes fragmentation mismatches with the physical network, leading to dropped packets for traffic exceeding the actual path MTU. An MTU mismatch between VIFs on the same bridge creates asymmetric connectivity failures.
Missing range validation. The mtu key is parsed by int_of_string with no bounds check. Valid Ethernet MTU ranges (68-9216 for standard/jumbo, maximum 65535 for theoretical) are not enforced.
Missing RBAC protection. VIF.other_config has zero map_keys_roles entries. The mtu key inherits the class default _R_VM_ADMIN.
No network-level consistency check. The VIF MTU is set independently of the bridge, physical NIC, and other VIFs on the same network. No check verifies that the MTU is compatible with the underlying network infrastructure.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Zero MTU | VIF rejects all frames, complete network loss for target VM | vm-admin | Source-traced |
| Oversized MTU | Fragmentation mismatch causes dropped packets and connectivity failures | vm-admin | Source-traced |
| Bridge MTU mismatch | Asymmetric MTU on same bridge causes intermittent failures for co-located VMs | vm-admin | Modeled |
| BOC-1 chain | vm-admin uses BOC-1 S3 to self-grant pool-operator, then manipulates MTU on all VIFs | vm-admin, BOC-1 | Source-traced |
VIF.other_config for mtu values outside normal range (1500-9000)disclosure/vendor-detection-guidance.mdVIF.other_config records for unexpected mtu valuesvm-admin delegated access to trusted administrators onlyAdd MTU range validation. Enforce bounds checking on the mtu value at write time (minimum 68, maximum 9216 for standard deployments, configurable upper bound for jumbo frame environments).
Add map_keys_roles protection. Restrict mtu to _R_POOL_ADMIN or _R_POOL_OP in the VIF field definition.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_xenops.ml:773-779 (MTU parsing with int_of_string, no range check), datamodel.ml:3914-3917 (VIF.other_config field definition, zero map_keys_roles)disclosure/advisories/vif-security-advisory.md (VIOC-3)research/investigations/vif-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.