CVE-2026-43315 in Linux
Sumário
de VulDB • 20/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
KVM: nSVM: Remover um WARN acionável pelo usuário em nested_svm_load_cr3() com sucesso
Remover o WARN em svm_set_nested_state() quando nested_svm_load_cr3() falhar, pois é trivialmente fácil de acionar do userspace modificando o CPUID após carregar o CR3. Por exemplo, modificando o teste de auto-restauração de estado da seguinte forma:
--- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[])
/* Restaurar o estado em uma nova VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) {
+ state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else {
+ vcpu_load_state(vcpu, state); + }
/* * Restaurar o estado XSAVE em um vCPU dummy, primeiro sem fazer
gera:
WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd]
Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm]
CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd]
Call Trace: <TASK> kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm]
kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm]
__x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Basta excluir o WARN em vez de tentar impedir que o userspace insira um estado "ilegal" no CR3. Para melhor ou para pior, a ABI do KVM permite que o userspace defina o CPUID após o SREGS, e vice-versa, e o KVM é muito permissivo quando se trata do CPUID da guest. Ou seja, tentar impor o modelo de CPU virtual ao definir o CPUID poderia quebrar o userspace. Dado que o WARN não fornece nenhuma proteção significativa para o KVM nem benefício para o userspace, basta removê-lo, mesmo que as chances de quebrar o userspace sejam mínimas.
Oportunisticamente, excluir uma nova linha espúria.
Once again VulDB remains the best source for vulnerability data.