CVE-2026-43315: Linux Kernel Privilege Escalation Flaw

CVE-2026-43315 Overview

CVE-2026-43315 affects the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem, specifically the nested SVM (Secure Virtual Machine) implementation for AMD processors. A local user with permissions to interact with the KVM ioctl interface can trigger a kernel WARN in svm_set_nested_state() by modifying CPUID after loading CR3. The condition originates in arch/x86/kvm/svm/nested.c where nested_svm_load_cr3() may fail on attacker-controlled state. The flaw allows a local, low-privileged user to taint the kernel and impact availability on systems where panic_on_warn is enabled.

Critical Impact
A local user with KVM access can trigger a kernel warning leading to denial of service on hosts configured with panic_on_warn, affecting availability of virtualization workloads.

Affected Products

Linux Kernel (KVM AMD / nSVM subsystem)
Systems running kvm_amd module with nested virtualization
Multi-tenant hosts exposing /dev/kvm to unprivileged users

Discovery Timeline

2026-05-08 - CVE-2026-43315 published to NVD
2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43315

Vulnerability Analysis

The vulnerability resides in the AMD nested virtualization path of KVM. The function svm_set_nested_state() contained a WARN_ON_ONCE assertion guarding the success of nested_svm_load_cr3(). The assertion assumed that once userspace had successfully loaded CR3 via the SREGS ioctl, subsequent restoration during nested state setup would also succeed. This assumption is incorrect because KVM's application binary interface (ABI) permits userspace to modify CPUID between SREGS and nested-state ioctls.

By lowering the guest's maximum physical address width via X86_PROPERTY_MAX_PHY_ADDR after setting a CR3 value that uses high bits (for example BIT(44)), userspace can render the previously valid CR3 invalid when KVM re-validates it during nested state load. The result is a WARNING at arch/x86/kvm/svm/nested.c:1877, a tainted kernel, and a stack trace through kvm_arch_vcpu_ioctl and kvm_vcpu_ioctl.

Root Cause

The root cause is an over-strict invariant inside KVM. The WARN treated user-controllable input as an internal correctness violation. Because KVM is intentionally permissive about guest CPUID and allows ioctl ordering flexibility, the WARN was trivially reachable from userspace without violating any documented contract.

Attack Vector

Exploitation requires local access and the ability to open /dev/kvm and issue vCPU ioctls. The attacker creates a vCPU, sets SREGS with a crafted CR3 value that relies on a wide physical address space, then sets CPUID to advertise a narrower MAXPHYADDR, and finally invokes KVM_SET_NESTED_STATE. The triggering sequence is captured in the upstream selftest modification to tools/testing/selftests/kvm/x86/state_test.c. On hosts with panic_on_warn=1, the WARN escalates from a logged taint to a kernel panic.

Detection Methods for CVE-2026-43315

Indicators of Compromise

Kernel log entries containing WARNING: CPU: ... at arch/x86/kvm/svm/nested.c referencing svm_set_nested_state
Tainted kernel flag [W]=WARN appearing after unprivileged user activity
Repeated KVM_SET_NESTED_STATE ioctl failures from non-root processes
Crash dumps on hosts with panic_on_warn enabled originating from kvm_amd

Detection Strategies

Monitor dmesg and /var/log/kern.log for WARN traces sourced from kvm_amd and correlate with the invoking PID and UID
Audit which local users and containers have access to /dev/kvm and the kvm group
Enable kernel auditd rules on ioctl syscalls targeting KVM character devices for privileged review

Monitoring Recommendations

Alert on kernel taint state transitions on virtualization hosts
Track KVM_SET_CPUID2 followed shortly by KVM_SET_NESTED_STATE from the same process as a suspicious sequence
Centralize host kernel logs to a SIEM and create detections for the svm_set_nested_state symbol in stack traces

How to Mitigate CVE-2026-43315

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the kernel.org stable commits that remove the user-triggerable WARN
Restrict /dev/kvm access to trusted users and service accounts only
Review panic_on_warn configuration on production hypervisors to assess blast radius

Patch Information

The fix removes the WARN in svm_set_nested_state() rather than attempting to constrain userspace CPUID ordering, since enforcing the virtual CPU model could break existing userspace. Stable backports are available across multiple branches via the Linux Kernel Commit Update, secondary backport, and additional stable branches.

Workarounds

Disable nested virtualization on AMD hosts by loading kvm_amd with nested=0 if nested guests are not required
Set panic_on_warn=0 on virtualization hosts to prevent WARN-driven panics until patches are applied
Constrain VM management to privileged orchestration daemons and remove direct user membership in the kvm group

bash

# Disable nested SVM until the patched kernel is deployed
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-amd.conf
sudo modprobe -r kvm_amd && sudo modprobe kvm_amd

# Ensure panic_on_warn is disabled on hypervisor hosts
sudo sysctl -w kernel.panic_on_warn=0