On XAPI-based hypervisors (XenServer, XCP-ng), arbitrary keys written to VIF.other_config - by administrators, automation tools, or upstream systems - become visible to the guest VM via xenstore when the VIF is backed by an SR-IOV virtual function. The standard VIF code path (Device.Vif.add at device.ml:827-829) applies a whitelist filter restricting keys to 7 known values (promiscuous, ethtool-rx, ethtool-tx, ethtool-sg, ethtool-tso, ethtool-ufo, ethtool-gso). The SR-IOV VIF code path (Device.NetSriovVf.add at device.ml:978-1006) completely omits this filter, passing all other_config keys to Generic.add_device as part of the xenserver_list parameter. These keys are written to a xenstore path with guest-readable permissions (rwperm_for_guest at device.ml:174-176). This violates the assumption that other_config is host-internal metadata.
VIF.other_config is a Map(String, String) field writable by vm-admin with zero map_keys_roles entries. XAPI passes the entire other_config map to xenopsd at xapi_xenops.ml:905.
For standard VIFs, xenopsd applies a whitelist:
(* device.ml:827-829 *)
let other_config =
List.filter (fun (x, _) -> List.mem x vif_udev_keys) other_config
For SR-IOV VIFs, this filter is absent:
(* device.ml:978-1006 *)
Generic.add_device ~xs device [] [] extra_private_keys
(extra_xenserver_keys @ other_config) ;
The unfiltered keys are written to the extra_xenserver_path with permissions granting the guest domain read access:
(* device.ml:174-176 *)
t.Xst.mkdirperms extra_xenserver_path
(Xenbus_utils.rwperm_for_guest device.frontend.domid) ;
t.Xst.writev extra_xenserver_path xenserver_list
This means any key-value pair in VIF.other_config on an SR-IOV VIF is readable by the guest domain via xenstore. Infrastructure metadata that administrators or automation tools write to other_config (e.g., internal identifiers, network topology hints, provisioning tags) becomes visible to the guest. This is an information disclosure that violates the assumption that other_config is a host-side metadata store.
Missing whitelist filter on SR-IOV path. The standard VIF path applies a whitelist; the SR-IOV path does not. The same security control exists but is inconsistently applied across code paths.
Guest-readable xenstore permissions. The extra_xenserver_path uses rwperm_for_guest, making all written keys readable by the guest domain.
Missing RBAC protection. VIF.other_config has zero map_keys_roles entries. Any key can be written by vm-admin.
Security equivalence assumption violation. Administrators expect standard VIFs and SR-IOV VIFs to have the same security properties. The missing whitelist breaks this assumption.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Infrastructure metadata disclosure | Guest reads host-internal metadata from VIF.other_config via xenstore | SR-IOV VIF, metadata in other_config | Source-traced |
| Network topology reconnaissance | Guest discovers internal network identifiers or topology hints | SR-IOV VIF, network metadata in other_config | Modeled |
| Provisioning data exposure | Guest accesses provisioning tags, internal IDs, or automation metadata | SR-IOV VIF, automation writes to other_config | Modeled |
| Deliberate injection | vm-admin writes arbitrary keys to SR-IOV VIF other_config, guest reads them as out-of-band communication | vm-admin, SR-IOV VIF | Source-traced |
VIF.other_config for writes to SR-IOV-backed VIFsdisclosure/vendor-detection-guidance.mdVIF.other_config on SR-IOV VIFs for sensitive metadataApply whitelist filter to SR-IOV path. Add the same vif_udev_keys whitelist to Device.NetSriovVf.add at device.ml:978-1006. This is a one-line fix:
let other_config =
List.filter (fun (x, _) -> List.mem x vif_udev_keys) other_config
Audit SR-IOV code path. If the whitelist was missed, other security controls may also be absent. Systematically compare Device.Vif.add and Device.NetSriovVf.add for divergences.
Add map_keys_roles protection. Restrict keys that should not be guest-visible to _R_POOL_ADMIN.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
device.ml:112-115 (vif_udev_keys whitelist definition), device.ml:827-829 (whitelist applied in Device.Vif.add), device.ml:978-1006 (whitelist absent in Device.NetSriovVf.add), device.ml:174-176 (extra_xenserver_path with rwperm_for_guest), xenops_server_xen.ml:4207-4264 (dispatch: standard VIF at line 4238 vs SR-IOV at line 4258), xapi_xenops.ml:905 (full other_config passthrough)disclosure/advisories/vif-security-advisory.md (VIOC-5)research/investigations/vif-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.