TL;DR: This post explains CVE-2022-42310, a flaw in Xen where guests can create orphaned nodes in Xenstore, possibly affecting the stability and security of virtualized environments. We’ll walk through how the vulnerability works, an example exploit, and resources for further reading.

What is Xenstore?

Xenstore is a database used by the Xen hypervisor to share configuration and runtime information between the host (Dom) and guest VMs (DomU). It’s a hierarchical key-value store, kind of like a filesystem, but used for VM metadata.

The Issue: Orphaned Nodes in Xenstore

CVE-2022-42310 is a vulnerability discovered in late 2022 affecting Xenstore. Here’s what happens:

Xenstore supports transactions so guest domains can batch a series of changes for consistency.

- If a guest tries to create multiple nodes inside a transaction, but an error happens during the process, the transaction cleanup code doesn’t fully remove (roll back) all the nodes that were partly created.
- Later, if the transaction is still committed, some nodes—*without a valid parent*—can be left as “orphans” in the database.

These orphan nodes persist and have no parent in the hierarchy, creating inconsistency.

This can be triggered intentionally by a malicious or buggy guest.

> Why is this bad?  
> Orphaned nodes can clutter the database, cause weird behaviors, and maybe even lead to privilege escalation or denial of service in certain scenarios.

Create Multiple Children: The guest also creates several “child” nodes under the new parent.

4. Induce an Error: The guest purposefully causes an error (e.g., by hitting a limit or using an invalid operation) before the transaction finishes.
5. Cleanup Fails: Xenstore’s error handling fails to fully clean up all the nodes created in the transaction.
6. Commit The Transaction: The guest commits the transaction. The parent node might be gone (because it was removed during cleanup), but the child nodes remain—now with no parent: they’re “orphans”.

Below is simple Python-like pseudocode that demonstrates how a guest could exploit this

import xenstore_lib

txn = xenstore_lib.start_transaction()

try:
    # Step 1: Create parent node
    xenstore_lib.mkdir(txn, "/local/domain/10/parent")
    
    # Step 2: Create child nodes
    xenstore_lib.mkdir(txn, "/local/domain/10/parent/child1")
    xenstore_lib.mkdir(txn, "/local/domain/10/parent/child2")

    # Step 3: Intentionally trigger an error (e.g., create duplicate)
    xenstore_lib.mkdir(txn, "/local/domain/10/parent")  # This should error

except xenstore_lib.XenstoreError:
    # Error happens here; inner state is inconsistent
    pass

# Step 4: Commit transaction (some nodes might not have a valid parent)
xenstore_lib.commit_transaction(txn)

After this, /local/domain/10/parent/child1 and /local/domain/10/parent/child2 could be present in the database *without* /local/domain/10/parent existing, making them orphans.

Access required: Guest access to Xenstore—usually granted by default to all guest VMs.

- Severity: Moderate, but with potential for stability/security issues.

Original patch:  
- Xen Security Advisory XSA-428  
- Xen git commit fixing CVE-2022-42310

How to Protect Against CVE-2022-42310

- Update Xen: If you run a Xen hypervisor, apply the patches provided in the links above. This is the ONLY sure way to mitigate the vulnerability.
- Restrict Untrusted Guests: If you can’t patch right away, avoid running untrusted or suspicious VMs that could try to exploit this bug.
- Monitor Xenstore: You can script a check for orphaned or deeply nested nodes in Xenstore to spot anomalies.

References

- Xen Security Advisory: XSA-428
- Detailed bug report: oss-security
- Commit fixing the issue: Git commit
- CVE Details

Conclusion

CVE-2022-42310 is a clear example of how even small data consistency bugs in low-level infrastructure like Xenstore can be dangerous. If you use Xen, make sure you understand the risk and patch as soon as possible. Orphaned Xenstore nodes might sound harmless, but they open the door to bigger security and stability issues in your virtualized stacks.

Timeline

Published on: 11/01/2022 13:15:00 UTC
Last modified on: 12/03/2022 14:14:00 UTC