A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can prevent a VM from starting by injecting a path traversal payload into VM.platform:parallel. The prefix check in vm_platform.ml:233-242 accepts any string starting with /dev/parport, but path traversal payloads such as /dev/parport../../tmp/marker pass the check and are forwarded to QEMU as the -parallel argument. QEMU's parport chardev backend expects a device node, not a file path - the payload causes QEMU initialization failure (ENOENT), preventing VM startup. No host filesystem read or write capability was confirmed - the impact is limited to VM denial-of-service.
VM.platform is a Map(String, String) field writable by vm-admin with zero map_keys_roles entries. The parallel key controls the QEMU -parallel device argument.
The code path:
vm-admin calls VM.add_to_platform(vm, "parallel", "/dev/parport../../tmp/marker")vm_platform.ml:233-242 validates the value:"none" or any string starting with /dev/parportAstring.String.is_prefix ~affix:"/dev/parport" - path traversal passesxenops_server_xen.ml:1945-1946-parallel <value> (device.ml:3975-3979)The investigation confirmed that QEMU's -parallel argument uses the parport chardev backend, not the file: backend. Unlike -serial file:path (PLAT-6), this does not create files on the host filesystem. Stock XCP-ng/XenServer disable CONFIG_PARPORT, so /dev/parportN device nodes do not exist even without path traversal.
Insufficient input validation. The prefix check at vm_platform.ml:233-242 accepts any string starting with /dev/parport. It does not reject path traversal sequences (../).
Missing RBAC protection. VM.platform has zero map_keys_roles entries. The parallel key is writable by vm-admin - the lowest delegated management role.
Write-time vs. start-time validation gap. The prefix check occurs at VM start (inside sanity_check), not at write time. An invalid value sits in the database until someone attempts to start the VM.
Missing device node validation. The check verifies a path prefix but does not validate that the path resolves to an actual character device node.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| VM startup DoS | Target VM cannot start due to QEMU crash on invalid parallel device path | vm-admin, target VM | Source-traced (investigation #368) |
| HA restart denial | HA-protected VM fails to restart after failover due to corrupted platform key | vm-admin, HA-protected target VM | Modeled |
| Persistent DoS | The key persists in the database; VM remains unstartable until key is removed | vm-admin | Source-traced |
VM.platform writes for the parallel key with values other than "none" or an exact /dev/parportN pathparallel key valuesdisclosure/vendor-detection-guidance.mdVM.platform records for unexpected parallel key valuesparallel keys from VM platform mapsReplace prefix check with exact device whitelist. The sanity_check function should accept only "none" or exact /dev/parportN paths (where N is 0-3). Reject any path containing .. or other traversal sequences.
Add map_keys_roles to VM.platform. Protect the parallel key at _R_POOL_ADMIN in datamodel_vm.ml.
Move validation to write time. Validate platform key values when they are set, not when the VM starts.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
vm_platform.ml:233-242 (prefix check), xenops_server_xen.ml:1945-1946 (xenopsd passthrough), device.ml:3975-3979 (QEMU command-line argument)disclosure/advisories/plat-security-advisory.md (PLAT-1)research/investigations/vm-platform.md, research/investigations/plat1-parport-attack-surface.mdDiscovered and reported by Jakob Wolffhechel, Moksha.