CVE-2026-43315

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding<br /> <br /> Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing<br /> as it is trivially easy to trigger from userspace by modifying CPUID after<br /> loading CR3. E.g. modifying the state restoration selftest like so:<br /> <br /> --- tools/testing/selftests/kvm/x86/state_test.c<br /> +++ tools/testing/selftests/kvm/x86/state_test.c<br /> @@ -280,7 +280,16 @@ int main(int argc, char *argv[])<br /> <br /> /* Restore state in a new VM. */<br /> vcpu = vm_recreate_with_one_vcpu(vm);<br /> - vcpu_load_state(vcpu, state);<br /> +<br /> + if (stage == 4) {<br /> + state-&gt;sregs.cr3 = BIT(44);<br /> + vcpu_load_state(vcpu, state);<br /> +<br /> + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36);<br /> + __vcpu_nested_state_set(vcpu, &amp;state-&gt;nested);<br /> + } else {<br /> + vcpu_load_state(vcpu, state);<br /> + }<br /> <br /> /*<br /> * Restore XSAVE state in a dummy vCPU, first without doing<br /> <br /> generates:<br /> <br /> WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd]<br /> Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm]<br /> CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd]<br /> Call Trace:<br /> <br /> kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm]<br /> kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x61/0xad0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Simply delete the WARN instead of trying to prevent userspace from shoving<br /> "illegal" state into CR3. For better or worse, KVM&amp;#39;s ABI allows userspace<br /> to set CPUID after SREGS, and vice versa, and KVM is very permissive when<br /> it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model<br /> when setting CPUID could break userspace. Given that the WARN doesn&amp;#39;t<br /> provide any meaningful protection for KVM or benefit for userspace, simply<br /> drop it even though the odds of breaking userspace are minuscule.<br /> <br /> Opportunistically delete a spurious newline.