CVE-2026-43315

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel KVM AMD nested virtualization path. A userspace process with access to KVM ioctls can manipulate virtual CPU state by setting CR3 and CPUID/nested state in an unusual but ABI-permitted order, causing the kernel to hit a WARN in svm_set_nested_state() after nested_svm_load_cr3(). On systems configured to panic on kernel warnings, this can crash the host; otherwise it can taint the kernel, generate noisy kernel logs, and disrupt virtualization reliability. The issue does not provide confidentiality or integrity impact by itself and requires local privileges sufficient to create or control a KVM virtual CPU.

Why it matters to the business

Organizations running Linux hosts with KVM, especially AMD-based systems using nested virtualization or allowing untrusted users to create/manage VMs, may face host instability or outages if the warning is triggered. The primary risk is availability: VM hosts could crash when panic-on-warning policies are enabled, interrupting workloads and requiring operational recovery. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known mature public exploitation, so urgency is highest for multi-tenant virtualization, CI/sandbox, developer lab, and cloud-like environments where users can access KVM.

How an attack unfolds

An attacker first needs local access to a Linux system and permission to interact with KVM, typically through membership in a group that can open /dev/kvm or through a virtualization management path that allows creation of guest vCPUs. The attacker creates or restores a virtual CPU state and intentionally sets an invalid or inconsistent CR3 value relative to the vCPU CPUID physical-address configuration. They then modify CPUID after setting special registers and submit nested SVM state through KVM ioctls. This reaches the AMD KVM nested virtualization handling code, where nested_svm_load_cr3() can fail and the vulnerable kernel executes a WARN in svm_set_nested_state(). If the host is configured with panic_on_warn, the WARN escalates into a kernel panic and host denial of service. If not, exploitation is limited to kernel warning logs, kernel tainting, and possible operational disruption from repeated triggering.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the upstream KVM nSVM fix removing the user-triggerable WARN in svm_set_nested_state(). No exact fixed package versions were provided in the input, so use distribution advisories for the affected kernel stream and confirm the backported KVM AMD nested virtualization patch is present. As interim mitigation, restrict access to /dev/kvm to trusted users only, review membership in groups such as kvm, avoid exposing KVM control to untrusted tenants or CI jobs, and consider disabling nested virtualization where it is not required. If operationally acceptable, review panic_on_warn settings: disabling panic-on-warning can reduce crash impact, but it should not be treated as a substitute for patching because the underlying trigger remains present.

How to confirm the fix worked

Confirm exposure by checking whether affected systems run Linux with KVM AMD support loaded or available, especially kvm_amd, and whether untrusted users can access /dev/kvm. Validate remediation by installing the vendor-fixed kernel and verifying the running kernel version after reboot. Confirm the fix through vendor changelogs or kernel source/backport metadata referencing removal of the WARN in KVM nSVM svm_set_nested_state() around nested_svm_load_cr3(). On test systems only, a KVM selftest-style reproduction that alters CR3 and CPUID ordering should no longer generate the kernel WARNING in svm_set_nested_state(). Also verify that /dev/kvm permissions are limited to intended administrative or virtualization service accounts.

Typical attack path

1. Gain local access to a Linux host that exposes KVM functionality.
2. Obtain permission to open and use /dev/kvm, directly or through a virtualization workflow.
3. Create or restore a KVM virtual CPU on an AMD SVM/nested virtualization capable host.
4. Set virtual CPU special registers with a CR3 value that becomes invalid for the later CPUID configuration.
5. Modify CPUID properties, such as maximum physical address width, after loading CR3.
6. Submit nested SVM state via KVM vCPU ioctls.
7. Trigger the WARN in svm_set_nested_state() in the kvm_amd module.
8. Cause a host panic if panic_on_warn is enabled, or generate kernel warnings and taint otherwise.

How to detect it

To determine whether this was already triggered, review kernel and system logs for KVM AMD warning traces. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, hypervisor monitoring logs, crash dump records, and kernel panic/oops collection systems. Look for WARNING entries where the stack includes svm_set_nested_state, nested_svm_load_cr3, kvm_arch_vcpu_ioctl, kvm_vcpu_ioctl, and the kvm_amd module. Correlate timestamps with local user sessions, virtualization management actions, CI jobs, VM restore/import operations, and processes opening /dev/kvm. If panic_on_warn is enabled, also inspect crash dumps, kdump/vmcore metadata, and out-of-band management logs for kernel panic events immediately preceded by KVM AMD warnings. There are no reliable network indicators because exploitation is local and occurs through KVM ioctls rather than a network protocol.

• WARNING: CPU:
• svm_set_nested_state
• nested_svm_load_cr3
• arch/x86/kvm/svm/nested.c
• kvm_amd
• kvm_arch_vcpu_ioctl
• kvm_vcpu_ioctl
• __x64_sys_ioctl
• Tainted: G W
• panic_on_warn
• /dev/kvm
• Comm: state_test

What your security team should do

• Inventory Linux KVM hosts, prioritizing AMD-based virtualization servers and systems with nested virtualization enabled.
• Patch affected kernels using distribution-supported updates that include the KVM nSVM fix, then reboot into the fixed kernel.
• Restrict /dev/kvm access to trusted users and remove unnecessary users or services from KVM-capable groups.
• Assess whether panic_on_warn is enabled on virtualization hosts and understand whether this vulnerability could produce a full host crash.
• Disable nested virtualization on hosts or VM pools that do not require it.
• Monitor kernel logs for WARN traces involving svm_set_nested_state, nested_svm_load_cr3, kvm_amd, and KVM vCPU ioctl paths.
• For shared developer, CI, sandbox, or multi-tenant VM infrastructure, treat this as higher priority despite low EPSS because local users may be able to trigger host-level disruption.
• Document vendor kernel versions containing the fix for each Linux distribution in use and enforce them through configuration/compliance tooling.