MOKSHA-2026-0025: Storage Protocol Metadata Poisoning via SR.sm_config (targetIQN/target/LUNid)

Summary

A pool-operator can corrupt storage protocol metadata by modifying targetIQN, target, datatype, or LUNid keys in SR.sm_config on iSCSI and HBA storage repositories. These keys are written by the SM driver during SR.create and read back during subsequent operations - but the field remains writable after creation. Modifying LUNid causes VDI operations to target the wrong LUN, enabling cross-SR data corruption. Modifying targetIQN or target causes SR misidentification and connection failures. This is an SR-level variant of the SMC-1 storage protocol injection - same architectural root cause, but at the SR level affecting all VDIs in the repository.

Vulnerability Description

SR.sm_config is a Map(String, String) field described as "SM dependent data" that serves as the primary configuration channel between XAPI and the SMAPIv1 storage driver framework. The field requires pool-operator to write and has zero map_keys_roles entries.

The data flow:

1. SM driver writes targetIQN, target, datatype, LUNid during SR.create (e.g., BaseISCSI.py:507-513)
2. Values are stored in the XAPI database
3. On subsequent SR.load() / SR.attach(), the driver reads these keys back
4. A pool-operator can modify the keys at any time via SR.set_sm_config or SR.add_to_sm_config
5. The driver uses the modified values in storage protocol operations

Key-Specific Impacts

Root Causes

1. Missing immutability enforcement. SR.sm_config keys set by the SM driver during SR.create remain writable via the API after creation. No immutability mechanism exists.

2. Missing RBAC protection. SR.sm_config has zero map_keys_roles entries. All driver-written keys are writable by pool-operator.

3. Backend trust assumption. SM drivers assume sm_config values are authoritative and have not been tampered with since creation.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared SM driver codebase)
• XCP-ng 8.3 - confirmed (source trace)

Storage Drivers Affected

Indirectly Affected

• iSCSI storage arrays - receive connections with wrong IQN or LUN mapping
• All VMs on affected SRs - data corruption or inaccessibility

Exploitation Scenarios

Detection

• Monitor SR.sm_config for modifications after SR creation
• Alert on targetIQN, target, LUNid, datatype key changes
• Compare SR.sm_config snapshots between scans for drift
• See rule S-03 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all iSCSI/HBA SR sm_config for unexpected values in targetIQN, target, LUNid
• Compare current sm_config values against known-good baselines
• Restrict pool-operator role grants

Long-Term Fix

Enforce sm_config immutability. Once set by the SM driver during SR.create, driver-written keys should not be modifiable via API. Implement a mechanism to distinguish driver-set keys from user-set keys.

Add map_keys_roles. Protect targetIQN, target, LUNid, datatype at _R_LOCAL_ROOT_ONLY.

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-0001 (BOC-1 RBAC collapse enables vm-admin to reach this vector)
• XAPI source: vendor/sm/drivers/BaseISCSI.py:507-513 (driver writes keys during create), SR.py (sm_config read path)
• Thematic advisory: disclosure/advisories/ssmc-security-advisory.md (SSMC-3)
• Investigation: research/investigations/sr-sm-config.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.