MOKSHA-2026-0084: Firmware Type Denial of Service via VM.HVM_boot_params firmware

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can disrupt VM boot by writing an invalid value to VM.HVM_boot_params:firmware or by removing the firmware key entirely. The firmware key is validated at VM start time (not at write time) by firmware_of_vm at xapi_xenops.ml:255-268, which pattern-matches against exactly "bios" and "uefi". Invalid values raise Server_error, preventing VM start. Removing the key causes fallback to BIOS firmware, which renders UEFI-installed operating systems unbootable. The impact is limited because the vm-admin role already has VM.hard_shutdown capability, making denial of service redundant with existing privileges. The VM.HVM_boot_params field has zero map_keys_roles entries.

Vulnerability Description

VM.HVM_boot_params is a Map(String, String) field defined at datamodel_vm.ml:55-58 with zero map_keys_roles entries.

The firmware key is consumed at VM start time:

let firmware_of_vm vm =
  match List.assoc "firmware" vm.API.vM_HVM_boot_params with
  | "bios" -> Bios
  | "uefi" -> Uefi (nvram_uefi_of_vm vm)
  | bad -> raise Api_errors.(Server_error (invalid_value, ["HVM-boot-params['firmware']"; bad]))
  | exception Not_found -> default_firmware

This is the strongest start-time validation of any infrastructure key observed in the audit. The firmware value is pattern-matched against exactly two valid strings. Any other value produces a Server_error at VM start. If the key is missing, default_firmware (Bios) is used as a fallback.

The vulnerability arises from the gap between write-time (no validation) and start-time (robust validation):

1. A vm-admin writes firmware=invalid - XAPI accepts and stores it without error
2. The next VM start attempt fails with Server_error
3. Alternatively, removing the firmware key causes BIOS fallback, which breaks UEFI guest OSes

The invalid value persists in the database until manually corrected by an administrator.

Root Causes

1. Missing write-time validation. XAPI accepts any value for the firmware key when written. Validation occurs only at VM start time.

2. Missing RBAC protection. VM.HVM_boot_params has zero map_keys_roles entries. The firmware key is writable by vm-admin.

3. Persistent invalid state. The invalid firmware value remains in the database after the VM start failure, requiring manual cleanup.

4. set_HVM_boot_params RBAC bypass. The set_HVM_boot_params method replaces the entire map and bypasses map_keys_roles per-key checks.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI codebase)
• XCP-ng - all versions (tested on 8.3.0)

Indirectly Affected

• UEFI guest VMs - firmware key removal causes fallback to BIOS, rendering UEFI guests unbootable
• Orchestration platforms - automated VM start operations fail with unexpected errors

Exploitation Scenarios

Chaining Analysis

• BOC-1 + HBP-2: BOC-1 provides root access enabling bulk corruption of HVM_boot_params across all VMs in the XAPI database. This converts a single-VM DoS into pool-wide VM start denial. However, BOC-1 provides far more destructive capabilities on its own.
• SMC-1: No interaction. Firmware selection does not touch storage protocol traffic.
• No novel escalation identified. The firmware validation at start time is robust. The DoS impact is redundant with existing vm-admin privileges (VM.hard_shutdown).

Detection

• Monitor VM.HVM_boot_params for firmware key modification or removal
• Alert on firmware key values other than bios or uefi
• Alert on firmware key removal on UEFI VMs
• See rule H-02 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VM.HVM_boot_params entries for unexpected firmware values
• Verify UEFI VMs have the correct firmware key present
• Restrict XAPI API access to trusted networks

Long-Term Fix

Add write-time validation. Validate the firmware value against {"bios", "uefi"} at write time in addition to start time. Reject invalid values immediately.

Add map_keys_roles protection. Restrict the firmware key to _R_POOL_ADMIN in datamodel_vm.ml.

Replace with typed field. The firmware key has exactly two valid values. It should be an enumeration field, not a string in a map.

Upstream patches exist. They are held privately pending coordinated disclosure.

Disclosure

Disclosure:

• Public release: 2026-04-24 08:00 CEST
• CERT/CC notified: 2026-04-23
• MITRE CVE reservation filed: 2026-04-09 (no response as of publication)
• EU CVE registers notified: 2026-04-18 (GCVE/CIRCL, ENISA, DIVD - no response)
• Vendor (Cloud Software Group / Citrix): not contacted pre-publication
• Downstream maintainer (Vates/XCP-ng): contacted 2026-04-23 with conditional patch offer

References

• Related MOKSHA IDs: MOKSHA-2026-0083 (HBP-1)
• XAPI source: datamodel_vm.ml:55-58 (VM.HVM_boot_params field definition), xapi_xenops.ml:255-268 (firmware_of_vm - start-time validation), xapi_xenops.ml:213-219 (assume_default_if_null_empty)
• Thematic advisory: disclosure/advisories/hbp-security-advisory.md (HBP-2)
• Investigation: research/investigations/vm-hvm-boot-params.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.