CVE-2026-43096: Linux Kernel mshv DoS Vulnerability

CVE-2026-43096 Overview

CVE-2026-43096 is a denial-of-service vulnerability in the Linux kernel's Microsoft Hypervisor (mshv) subsystem. The flaw resides in mshv_handle_gpa_intercept(), which attempts to remap pages on every guest-physical-address (GPA) fault against movable memory regions without validating the access type against region permissions. When a guest writes to a read-only region, the remap succeeds but the region remains read-only, causing the vCPU to immediately re-fault and spin indefinitely. The condition produces an infinite fault loop that consumes host CPU resources.

Critical Impact
A malicious guest can intentionally trigger permission-denied GPA intercepts to spin a vCPU indefinitely, exhausting host resources and creating a denial-of-service condition against the hypervisor host.

Affected Products

Linux kernel builds containing the mshv (Microsoft Hypervisor) root partition driver
Hosts running Linux as a Hyper-V root partition with mshv_handle_gpa_intercept() in the call path
Stable kernel branches prior to the fixes referenced in commits 02226839079c and 16cbec248976

Discovery Timeline

2026-05-06 - CVE-2026-43096 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43096

Vulnerability Analysis

The mshv driver provides Linux support for acting as a Microsoft Hypervisor root partition. When a guest accesses guest-physical memory that is not present or has restricted permissions, the hypervisor delivers a GPA intercept to the host, which is dispatched through mshv_handle_gpa_intercept().

The function unconditionally attempts to remap the offending page for any fault on a movable memory region. It does not compare the intercept's access type (read, write, or execute) against the permissions configured for the target region. As a result, a write fault against a read-only region triggers a remap that completes successfully but does not change the region's permissions. Control returns to the guest, which immediately re-issues the same write, generating the same intercept, and the cycle repeats.

The loop occupies the vCPU thread on the host and prevents forward progress. A guest with the ability to issue arbitrary memory accesses can convert this behavior into a sustained DoS against the host kernel.

Root Cause

The root cause is missing input validation in the intercept handler. The code path treats every fault as a candidate for remapping rather than first checking whether the requested access is permitted by the region descriptor. Writes to non-writable regions and execute attempts against non-executable regions are not rejected, so the handler returns a success path that the hypervisor interprets as resolved, leading to immediate re-fault.

Attack Vector

The attack vector is local to the virtualization boundary. A guest VM running on an affected Linux root partition issues a write to a read-only GPA region, or an instruction fetch from a non-executable region. Because no privileged guest API call is required and any write to mismapped memory suffices, an unprivileged process inside a malicious or compromised guest can trigger the loop. The fix validates the intercept access type against region permissions and returns false for disallowed accesses, allowing the Virtual Machine Monitor (VMM) to handle the intercept appropriately rather than spinning the vCPU.

No public exploit code is available for CVE-2026-43096. Technical details are documented in the upstream patches referenced under Kernel Git Commit 02226839079c and Kernel Git Commit 16cbec248976.

Detection Methods for CVE-2026-43096

Indicators of Compromise

Sustained 100% CPU utilization on a single vCPU thread (KVM/mshv worker) with no corresponding guest workload activity
High frequency of GPA intercepts originating from the same guest physical address as observed in mshv tracepoints
Guest VM unresponsiveness combined with elevated host kernel CPU time attributed to hypervisor intercept handling

Detection Strategies

Enable mshv and hypervisor tracepoints to count GPA intercepts per guest and alert when the rate per second exceeds a baseline threshold
Correlate per-vCPU CPU consumption with intercept counts to identify loops where intercepts increment without forward execution progress
Audit kernel logs for repeated mshv_handle_gpa_intercept activity tied to the same GPA and access type

Monitoring Recommendations

Track per-VM and per-vCPU host CPU time and flag deviations from historical baselines on Hyper-V root partitions
Forward host kernel telemetry to a centralized analytics pipeline for behavioral correlation across the virtualization fleet
Monitor guest scheduling latency and vCPU runnable-but-not-progressing states as a proxy for intercept loops

How to Mitigate CVE-2026-43096

Immediate Actions Required

Apply the upstream kernel patches referenced in commits 02226839079c and 16cbec248976 and rebuild affected kernels
Update Hyper-V root partition hosts to a stable kernel release that includes the fix
Restrict guest VM creation and memory configuration changes to trusted operators until patches are deployed

Patch Information

The fix validates intercept access type against region permissions inside mshv_handle_gpa_intercept(). Writes to non-writable regions and executes against non-executable regions are rejected early, and the handler returns false so the VMM can deliver the fault to the guest or terminate the VM. The patches are available in the stable tree as commit 02226839079c and commit 16cbec248976.

Workarounds

Avoid exposing movable memory regions with restrictive permissions to untrusted guests until patched kernels are in place
Apply per-VM CPU quotas (cgroup CPU controllers) to cap host impact from a runaway vCPU thread
Configure host watchdogs to detect sustained single-vCPU saturation and forcibly terminate the offending guest

bash

# Example: cap a guest's host CPU consumption via cgroup v2 to bound DoS impact
mkdir -p /sys/fs/cgroup/vm-guest1
echo "50000 100000" > /sys/fs/cgroup/vm-guest1/cpu.max   # 50% of one CPU period
echo <vmm-pid> > /sys/fs/cgroup/vm-guest1/cgroup.procs