CVE-2026-23401: Linux Kernel Privilege Escalation Flaw

CVE-2026-23401 Overview

CVE-2026-23401 is a flaw in the Linux kernel's Kernel-based Virtual Machine (KVM) x86 memory management unit (MMU) implementation. When KVM installs an emulated Memory-Mapped I/O (MMIO) Shadow Page Table Entry (SPTE), it fails to drop or zap an existing shadow-present SPTE first. A local, authenticated user with access to KVM can trigger a WARNING in mark_mmio_spte() and destabilize the host kernel through guest page-fault handling. The defect affects multiple Linux kernel releases, including 7.0 release candidates and stable branches that received the regression from commit a54aa15c6bda3.

Critical Impact
A local user with KVM access can crash or hang the host kernel by manipulating shadowed guest page table entries to transition between memslots and emulated MMIO regions.

Affected Products

Linux Kernel 5.13 (specific stable branch)
Linux Kernel 7.0 release candidates rc1 through rc7
Multiple Linux Kernel stable branches addressed by the listed upstream commits

Discovery Timeline

2026-04-01 - CVE-2026-23401 published to the National Vulnerability Database
2026-04-24 - Last updated in NVD database

Technical Details for CVE-2026-23401

Vulnerability Analysis

The defect lives in arch/x86/kvm/mmu/mmu.c within the KVM x86 shadow paging logic. KVM uses SPTEs to map guest physical addresses to host physical pages. A specialized class of SPTE marks emulated MMIO ranges so that guest accesses trap to the hypervisor for device emulation.

The original commit a54aa15c6bda3 assumed that a shadow-present SPTE could never be converted to an MMIO SPTE through a guest write. That assumption ignores writes to guest memory issued by host userspace outside KVM's direct control. When host userspace modifies a shadowed guest page table entry (gPTE) so a mapping moves from a memslot-backed region to emulated MMIO, the next guest page fault on that address takes the MMIO path while the prior shadow-present SPTE remains installed.

The resulting state triggers a WARN_ON(is_shadow_present_pte(*sptep)) inside mark_mmio_spte(). The kernel call chain runs through mmu_set_spte → ept_page_fault → kvm_mmu_do_page_fault → kvm_mmu_page_fault → vmx_handle_exit, leaving the MMU in an inconsistent state.

Root Cause

The root cause is a missing precondition check in the MMIO SPTE installation path. The fix drops or zaps any existing shadow-present SPTE before writing the new MMIO SPTE, ensuring the MMU tracking structures remain consistent regardless of how the underlying gPTE was modified.

Attack Vector

The attack vector is local. An attacker requires the ability to run a KVM-enabled process on the host (typically a virtualization user with /dev/kvm access). By driving a guest workload while modifying shadowed guest page tables from the host userspace controller, the attacker forces KVM down the inconsistent code path. Successful exploitation produces a kernel warning, MMU corruption, and a denial-of-service condition on the host. Confidentiality and integrity are not impacted; availability is.

No public proof-of-concept exploit is associated with CVE-2026-23401, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2026-23401

Indicators of Compromise

Kernel log entries containing WARNING: arch/x86/kvm/mmu/mmu.c and the symbol mark_mmio_spte+
Stack traces in dmesg showing mmu_set_spte, ept_page_fault, and kvm_mmu_page_fault immediately preceding host instability
Unexpected kvm_intel or kvm module faults correlated with guest VM page-fault activity

Detection Strategies

Monitor /var/log/kern.log and journalctl -k for KVM MMU WARN traces on hypervisor hosts
Audit hosts running affected kernel versions by parsing uname -r output against the fixed commit list
Correlate guest crashes or VM exits with host-side kernel warnings to identify reproducible trigger patterns

Monitoring Recommendations

Forward hypervisor kernel ring buffers to a centralized log platform and alert on kvm module warnings
Track which local accounts hold access to /dev/kvm and /dev/vfio device nodes
Baseline normal vmx_handle_exit rates and alert on sudden spikes that may indicate exploitation attempts

How to Mitigate CVE-2026-23401

Immediate Actions Required

Inventory all Linux hypervisor hosts running affected kernel versions, including 7.0 release candidates and the 5.13 stable branch
Apply the upstream stable kernel updates referenced in the Linux Kernel Commit #20656cd1 and related fix commits
Restrict /dev/kvm access to trusted virtualization service accounts only

Patch Information

The fix is distributed across seven upstream commits in the stable trees. Reference commits include Linux Kernel Commit #45915815, Linux Kernel Commit #695320de, Linux Kernel Commit #aad885e7, Linux Kernel Commit #bce7fe59, Linux Kernel Commit #ed590999, and Linux Kernel Commit #fd28c561. Each patch reorders the MMIO SPTE installation so the existing shadow-present SPTE is dropped or zapped first.

Workarounds

Limit KVM usage to trusted operators until patched kernels are deployed across the fleet
Disable nested virtualization features on hosts that do not require them to reduce MMU shadowing complexity
Schedule rolling reboots after kernel package updates to ensure the patched kernel is active on every hypervisor

bash

# Verify the running kernel version and confirm KVM module status
uname -r
lsmod | grep -E '^kvm(_intel|_amd)?'

# Restrict /dev/kvm access to a dedicated virtualization group
sudo groupadd -f kvm
sudo chown root:kvm /dev/kvm
sudo chmod 0660 /dev/kvm

# Watch for the specific WARN signature after applying mitigations
sudo dmesg -w | grep -i 'mark_mmio_spte\|arch/x86/kvm/mmu'