CVE-2026-42493: Xen Hypervisor DoS Vulnerability

CVE-2026-42493 Overview

CVE-2026-42493 documents the deprecation of Xen shadow paging functionality due to unresolved resource-exhaustion issues. Operations involving shadow paging can run excessively long without preemption, creating a denial-of-service condition against the hypervisor. The Xen Project has chosen to deprecate the feature rather than continue addressing these preemption issues at high engineering cost. Alternatives such as Hardware Assisted Paging (HAP) for HVM/PVH guests and the PV-shim for PV guests remain available. Small memory-footprint guests may still be safe to operate under shadow paging. The issue is tracked under [CWE-400] Uncontrolled Resource Consumption.

Critical Impact
A malicious guest can trigger long-running, non-preemptible shadow paging operations that exhaust host CPU resources and degrade or halt hypervisor availability.

Affected Products

Xen hypervisor deployments using shadow paging mode
HVM/PVH guests configured without Hardware Assisted Paging (HAP)
PV guests running without the PV-shim wrapper

Discovery Timeline

2026-07-28 - CVE-2026-42493 published to NVD
2026-07-28 - Last updated in NVD database

Technical Details for CVE-2026-42493

Vulnerability Analysis

The vulnerability resides in Xen's shadow paging subsystem. Shadow paging maintains software-managed page tables that mirror guest page tables when hardware-assisted paging is unavailable or disabled. Certain shadow paging operations traverse or modify large data structures and lack fine-grained preemption checkpoints. A guest can induce these long-running operations, monopolizing a physical CPU inside the hypervisor context. The Xen Project determined that engineering preemption into these code paths was not sustainable. Instead, the functionality is deprecated in favor of Hardware Assisted Paging (HAP) and the PV-shim, both of which avoid the affected code paths.

Root Cause

The root cause is the absence of preemption points inside shadow paging operations that can scale with guest memory size. When a guest triggers operations against large memory ranges, the hypervisor executes them to completion without yielding, blocking scheduling and event handling on the affected physical CPU. This is a classic uncontrolled resource consumption pattern classified under [CWE-400].

Attack Vector

An attacker with control over a guest domain can invoke operations that drive expensive shadow paging updates. Because the operations are non-preemptible, the guest can hold hypervisor CPU time and produce a host-level availability impact. No authentication to the host is required, and the trigger is network-reachable only in the sense that a compromised guest workload is sufficient to initiate the condition.

No verified exploit code is publicly available. Refer to the Xen Project Security Advisory XSA-495 for technical details.

Detection Methods for CVE-2026-42493

Indicators of Compromise

Sustained 100% utilization on individual physical CPUs assigned to dom0 or specific guests without corresponding guest workload
Hypervisor log entries indicating stalled scheduler ticks or watchdog warnings tied to shadow paging code paths
Guest domains configured with shadow_memory allocations and large maxmem values

Detection Strategies

Inventory all Xen hosts and identify guests running in shadow paging mode rather than HAP or PV-shim
Correlate host CPU saturation events with guest memory operations such as ballooning, live migration, or large allocations
Alert on Xen console messages referencing shadow page table teardown or preemption timeouts

Monitoring Recommendations

Collect xl vcpu-list and xl info output on a schedule to track vCPU time skew and shadow memory pressure
Forward hypervisor logs to a central data lake and baseline normal shadow paging activity to detect anomalies
Monitor guest-to-host CPU ratios and flag guests that consistently consume disproportionate hypervisor CPU cycles

How to Mitigate CVE-2026-42493

Immediate Actions Required

Identify guests currently running under shadow paging and migrate them to HAP where hardware supports Intel EPT or AMD NPT
For PV guests that cannot use HAP directly, deploy the PV-shim wrapper to run them as HVM/PVH guests with HAP enabled
Restrict shadow paging to small, trusted guests where the resource consumption risk is bounded and accepted

Patch Information

No code patch is being issued. The Xen Project has deprecated shadow paging rather than resolve the underlying preemption cost. Consult the Xen Project Security Advisory XSA-495 and the OpenWall OSS Security discussion for the authoritative guidance.

Workarounds

Enable Hardware Assisted Paging (HAP) for all HVM and PVH guests on hardware that supports it
Wrap PV guests in the PV-shim to eliminate reliance on shadow paging in the host hypervisor
Cap maxmem and shadow_memory values on any guest that must remain on shadow paging to limit worst-case operation duration
Isolate untrusted guests onto dedicated hosts if shadow paging cannot be removed

bash

# Example: enable HAP for an HVM guest in its xl configuration
# /etc/xen/<guest>.cfg
builder = "hvm"
hap = 1
memory = 2048
maxmem = 2048
# Avoid overprovisioning shadow_memory on legacy configurations
# shadow_memory = 8