MOKSHA-2026-0053: MTU Manipulation (0-65535) via VIF.other_config

Advisory IDMOKSHA-2026-0053
Semantic IDVIOC-3
Published2026-04-24
CVSS 3.15.3 Medium
CVSS 3.1 VectorAV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 4.05.3 Medium
CVSS 4.0 VectorAV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L
XAPI ObjectVIF
XAPI Fieldother_config:mtu
Entry Rolevm-admin
ResearcherJakob Wolffhechel, Moksha

Affected Products

VendorProductVersions
Citrix / Cloud Software GroupXenServer / Citrix Hypervisorall versions (shared XAPI codebase)
VatesXCP-ng8.3.0

Summary

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.

Vulnerability Description

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:

  1. vm-admin sets an extreme MTU value: VIF.add_to_other_config(vif, "mtu", "65535")
  2. XAPI reads the value at xapi_xenops.ml:773 using int_of_string
  3. No range validation is performed - any integer value is accepted
  4. The MTU is applied to the VIF's network interface via ip link set mtu <value>
  5. The host kernel processes the MTU change

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.

Root Causes

  1. 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.

  2. Missing RBAC protection. VIF.other_config has zero map_keys_roles entries. The mtu key inherits the class default _R_VM_ADMIN.

  3. 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.

Affected Systems

Directly Affected

Indirectly Affected

Exploitation Scenarios

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

Chaining Analysis

Detection

Remediation

Short-Term Mitigations

Long-Term Fix

Add 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

Disclosure:

References

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.

Jakob Wolffhechel · Moksha · Copenhagen
jakob@wolffhechel.dk · +45 3170 7337
Published 2026-04-24 08:00 CEST · cna.moksha.dk · shittrix.moksha.dk