When running virtual machines, isolation and resource management are the pillars of security. Sometimes, even small mistakes in cleaning up resources can lead to critical vulnerabilities—and that’s exactly what happened with CVE-2022-23035. Let’s break down what happened, how it could be exploited, and why it matters.

What Is CVE-2022-23035?

In Xen, a popular open-source hypervisor, physical devices can be made available (passed-through) to guest virtual machines (VMs). These devices use interrupts (IRQs) to signal events. When a VM is done with a device, the hypervisor needs to clean up those interrupts carefully.

The bug behind CVE-2022-23035 is an insufficient cleanup of those IRQs when used by x86 HVM (hardware virtual machine) guests. If a device was not done sending interrupts ("not quiescent") when cleanup started, a retry should have been scheduled—but due to a flaw, it wasn’t always. This could cause the system to:

Or try to use NULL pointers (NULL pointer dereference).

This opens the door to guest VMs crashing the host, leaking information, or possibly escalating privileges.

Why Does This Happen?

The Xen hypervisor maintains structures to track IRQs for passed-through devices. As cleanup occurs, especially if multiple interrupts are still pending, the code is supposed to loop and safely retry if things aren't ready.

The bug happens when cleanup is interrupted (say, because a device is still trying to send its last interrupt) while multiple IRQs are involved. The code skips scheduling another round of cleanup. That leaves pointers in an indeterminate state—already cleared or freed—yet other parts of Xen still think they're usable.

Breaking Down the Code

Let’s look at a simplified snippet that sketches what went wrong. (This is illustrative pseudo-code, not the exact code from Xen.)

// Imaginary resource struct for a device IRQ
struct dev_irq {
    void *data;
    bool is_active;
    // ... other fields
};

// Clean up IRQs for a device, assuming several could be pending
void cleanup_irqs(struct dev_irq *irqs[], int num_irqs) {
    for (int i = ; i < num_irqs; i++) {
        if (!irqs[i]->is_active) {
            free(irqs[i]->data);   // Data is now invalid
            irqs[i]->data = NULL;  // Pointer cleared
            free(irqs[i]);         // Entire struct is freed
            irqs[i] = NULL;
        } else {
            // Device is still signaling, need to retry cleanup later
            // ... (BUG: maybe doesn't actually reschedule retry!)
        }
    }
    // elsewhere in code...
    // irqs[i]->data is assumed valid, but could be NULL or dangling!
}

Because the code doesn't always reschedule a retry, the system could walk away thinking those pointers are still valid, but in reality, some have been freed or nulled out—leading to crashes or, worse, security holes.

Race condition develops: concurrent code may interact with now-freed or null pointers.

5. Result: Host crash (DoS), leaked memory, or in edge cases, privilege escalation if the freed memory is reallocated maliciously.

Proof-of-Concept Test

While it’s not trivial to cause this exact scenario intentionally, here’s a broad-strokes demonstration a pen-tester might use to test for the bug. (Never run test code on production systems.)

# Example: Rapidly cycle assignment and removal of a PCI pass-through device in a loop VM
for i in $(seq 1 100); do
  xl pci-attach <vmname> 000:06:00.
  # Guest triggers the device to generate many interrupts
  xl pci-detach <vmname> 000:06:00.
done
# Watch for host logs or crashes

Refer to Xen's documentation on PCI passthrough for the specific commands and device assignments.

What You Should Do

The Xen Project issued a fix and advisory as XSA-393. If you run Xen on hardware with device-passthrough support for guests, you must upgrade to a patched release or apply the patch from the advisory.

Further References

- Xen Security Advisory XSA-393
- CVE Details: CVE-2022-23035
- Xen PCI Passthrough Guide
- Xen Project Downloads

Closing Thoughts

CVE-2022-23035 is a reminder that resource cleanup in code—especially for low-level virtualization tasks—has to be done with extreme care. Small logic errors can open big holes. If you’re using device pass-through with Xen, patch now—don’t wait!

Stay safe, and always keep your virtualization stacks up to date.

Timeline

Published on: 01/25/2022 14:15:00 UTC
Last modified on: 08/19/2022 09:59:00 UTC