MOKSHA-2026-0065: SCSI Identity Forgery in XAPI Database via VDI.xenstore_data

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can inject forged SCSI INQUIRY data into VDI.xenstore_data, replacing the SM-generated SCSI device identity and serial number values in the XAPI database. The scsi/0x12/0x83 (device ID) and scsi/0x12/0x80 (serial number) keys are normally generated by SM drivers via scsiutil.py:335-353 during VDI attach. By writing forged values to the database field, an attacker poisons the disk identity metadata visible to downstream consumers. Forged SCSI data propagates through snapshot and clone operations (xapi_vdi.ml:861-862), potentially causing disk misidentification in backup, disaster recovery, and inventory systems.

Vulnerability Description

SM drivers generate synthetic SCSI INQUIRY pages during VDI attach. These values serve as disk identity metadata:

• scsi/0x12/0x80 - SCSI page 0x80: unit serial number
• scsi/0x12/0x83 - SCSI page 0x83: device identification (NAA, vendor-specific)
• scsi/0x12/default - default INQUIRY response

These values are generated by scsiutil.update_XS_SCSIdata() at scsiutil.py:335-353 and flow to guest xenstore sm-data/ through the SM runtime path. The XAPI database field VDI.xenstore_data stores a separate copy that is not consulted during the active attach path.

However, the database copy is consumed by:

1. Snapshot/clone operations that copy xenstore_data to new VDI records
2. API consumers that read VDI records (backup tools, inventory scanners)
3. Pool join operations that copy VDI records across pool boundaries

A vm-admin can forge these values:

VDI.add_to_xenstore_data(vdi, "scsi/0x12/0x83", "<forged-device-id>")
VDI.add_to_xenstore_data(vdi, "scsi/0x12/0x80", "<forged-serial>")

Root Causes

1. No key validation. The field accepts any key, including SCSI identity keys that are SM-internal metadata. There is no whitelist restricting which keys a user can set.

2. No provenance tracking. There is no distinction between SCSI data written by SM drivers and SCSI data written by API users. Both are stored in the same field with identical structure.

3. Missing RBAC protection. Zero map_keys_roles entries. A vm-admin has full write access to storage identity metadata.

4. Propagation without verification. Snapshot, clone, and pool join operations copy xenstore_data without re-validating the SCSI identity values against the SM driver output.

Affected Systems

Directly Affected

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

Indirectly Affected

• Windows guest drivers - some Windows MPIO and disk management drivers use SCSI page 0x83 for disk identification
• Backup systems - disk identification for incremental backup and disaster recovery relies on SCSI identity metadata
• Inventory/CMDB systems - aggregate SCSI identity data for asset tracking

Exploitation Scenarios

Chaining Analysis

• VXD-2 + VXD-3: Forged SCSI identities (VXD-2) propagate through snapshot/clone hierarchies (VXD-3), multiplying the impact of a single injection.
• VXD-2 + VXD-4: Forged identities cross pool boundaries via pool join (VXD-4), spreading to target pools.
• BOC-1 + VXD-2: Root access via BOC-1 enables bulk SCSI identity forgery across all VDIs in the pool.

Detection

• Compare VDI.xenstore_data SCSI keys against SM driver output for the same VDI
• Alert on scsi/0x12/* keys that change outside of normal SM operations (VDI attach/create)
• Monitor for SCSI identity values that do not match the expected format for the SR type
• See rule D-02 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VDI.xenstore_data records for unexpected scsi/0x12/* values
• Cross-validate SCSI identities against SM driver output
• Restrict vm-admin delegated access to trusted administrators

Long-Term Fix

Restrict write access. Change the field write role to _R_POOL_ADMIN or _R_LOCAL_ROOT_ONLY.

Add key validation. Reject writes to SM-internal keys (scsi/*, vdi-uuid, storage-type, vdi-type) from non-SM sessions.

Tag provenance. Distinguish SM-generated vs. user-written entries in the database so consumers can verify the source.

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

• XAPI source: datamodel.ml:6352-6369 (field definition), scsiutil.py:335-353 (SM-generated SCSI identity data), xapi_vdi.ml:861-862 (snapshot/clone copies xenstore_data), xapi_pool.ml:1215 (pool join copies xenstore_data)
• Thematic advisory: disclosure/advisories/vxd-security-advisory.md (VXD-2)
• Investigation: research/investigations/vdi-xenstore-data.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.