Security flaws in the virtualization stack often have long and surprising after-effects. CVE-2022-42320 is a prime example of how a small detail in access control can give rise to a real security hole. Put simply, this bug allows a new Xen guest to inherit access to leftover configuration nodes in Xenstore—if those nodes were tied to a previously deleted VM that happened to have the same domain ID.

Let’s break down what’s going on, why it matters, show some exploit details, and discuss how you can stay safe.

What is Xenstore, and What's the Problem?

Xenstore is a key-value store used by the Xen hypervisor to manage VM (domain) configuration details. Every node in Xenstore can have access rights tied to specific domain IDs (domids).

When a guest VM is deleted, its domid is freed up—but some Xenstore nodes with their permission entries might hang around. Usually, their permissions get fixed the next time they’re written to, so it doesn’t seem like a big deal.

But here's the real issue:  
When a new VM is booted, it might get the same domid as a previously deleted VM (because Xen recycles domids). For a short time right before the new VM is officially attached to Xenstore by dom (the control domain), there’s a window where access rights tied to the _old_ VM's domid are still valid. If another domain (VM) updates such a node during this window, the new guest can sneak in and access nodes it shouldn’t.

VM-A is running with domid N.

2. VM-A is deleted. Some Xenstore nodes (let’s say /local/domain/N/sensitive_data) still exist and have access rights allowing domid N.

Xen reuses domid N for a brand new VM-B.

4. Before VM-B is fully attached, another VM quickly writes to /local/domain/N/sensitive_data. This makes the permissions valid for the new guest (VM-B).
5. VM-B boots, finds /local/domain/N/sensitive_data and can now read (or write) data intended only for the old VM-A.

This trick can reveal sensitive configs, credentials, or even inter-VM secret communication.

Code Example: Accessing Stale Xenstore Nodes

Here’s an oversimplified Python example using xenstore’s client tools.

Suppose a malicious VM tries to enumerate all nodes matching its domid after boot

import subprocess
import os

# domid of the victim (reused by attack VM)
domid = os.environ.get('DOMID', '5')

# Try to read all keys under /local/domain/<domid>
def read_xenstore_keys(domid):
    path = f"/local/domain/{domid}"
    try:
        # 'xenstore-ls' walks the tree; output might be filtered for sensitive info
        result = subprocess.check_output(["xenstore-ls", path], universal_newlines=True)
        print(f"Xenstore for domid {domid}:\n{result}")
    except Exception as e:
        print(f"Error: {e}")

if __name__ == '__main__':
    read_xenstore_keys(domid)

If the attacker’s VM is started with the same domid as a previously deleted domain, and if another domain wrote to those nodes before the new VM initialized, the attacker will see and possibly edit whatever secret data was left behind.

Control over two VMs: One to delete and one to create with the same domid.

2. A cooperative (or compromised) second domain that writes to the stale Xenstore node before the new guest is attached.
3. Automation: Since the timing window is narrow (milliseconds to seconds), automation is key. For example:

# In attacker VM, loop reading possible leftover nodes
while : ; do
    xenstore-ls /local/domain/$DOMID | grep 'password'
    sleep .1
done
# On another VM or dom, write to the node just after the old VM is deleted and before the new VM initializes
xenstore-write /local/domain/$DOMID/password 'supersecret'

Security boundaries: Hypervisor-enforced isolation is compromised.

- Chaining attacks: If sensitive info (credentials, keys, tokens) are stored in Xenstore, other exploits may follow.

How Was This Fixed?

The Xen team closed the window by ensuring that, when a new domain is attached to Xenstore, all nodes with that domid in their access list are purged or sanitized, killing old access rights.

- Official Xen advisory
- Patch Link

> "Ensure that access rights containing a domid are sanitized when a new domain is being introduced with that domid."

Should I Worry? How Can I Protect Myself?

Affected Xen versions should be patched as soon as possible.

Avoid exposing sensitive data in Xenstore.

- Minimize domid reuse by not deleting/creating guests rapidly.

References and Further Reading

- Xen Security Advisory: XSA-422
- Upstream Patch: Git commit
- CVE details: CVE-2022-42320 on MITRE
- Xenstore Documentation: xenstore.7 man page

Final Thoughts

CVE-2022-42320 teaches us that quirky bugs can live in the low-level plumbing of our virtual machines—and that subtle timing issues can break security assumptions. If you use Xen with guests you don’t fully trust, this is a wake-up call. Patch now, and keep your eyes open for similar bugs!

*This long-read is an exclusive breakdown—feel free to share, but always credit the Xen Project team for the original discovery and fix!*

Timeline

Published on: 11/01/2022 13:15:00 UTC
Last modified on: 11/29/2022 18:29:00 UTC