CVE-2026-23005

Resumo

No kernel, a seguinte vulnerabilidade foi resolvida: x86/fpu: Limpar XSTATE_BV[i] no estado XSAVE do convidado sempre que XFD[i]=1 Ao carregar o estado XSAVE do convidado via KVM_SET_XSAVE, e ao atualizar XFD em resposta a um WRMSR do convidado, limpar as funcionalidades desativadas por XFD no XSTATE_BV salvo (ou a ser restaurado) para garantir que o KVM não tente carregar estado para funcionalidades que estão desativadas via o XFD do convidado. Como o kernel executa XRSTOR com o XFD do convidado, salvar XSTATE_BV[i]=1 com XFD[i]=1 fará com que XRSTOR gere #NM e cause pânico no kernel. Por exemplo, se fpu_update_guest_xfd() define XFD sem limpar XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- Isto pode acontecer se o convidado executar WRMSR(MSR_IA32_XFD) para definir XFD[18] = 1, e uma IRQ do host acionar kernel_fpu_begin() antes da chamada do manipulador de vmexit a fpu_update_guest_xfd(). e se o espaço do usuário preencher XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- O novo comportamento é consistente com a arquitetura AMX. De acordo com o SDM da Intel, XSAVE salva XSTATE_BV como '0' para componentes que estão desativados via XFD (e XSAVE não compactado salva a configuração inicial do componente de estado): Se XSAVE, XSAVEC, XSAVEOPT, ou XSAVES estiver salvando o componente de estado i, a instrução não gera #NM quando XCR0[i] = IA32_XFD[i] = 1; em vez disso, opera como se XINUSE[i] = 0 (e o componente de estado estivesse no seu estado inicial): salva o bit i do campo XSTATE_BV do cabeçalho XSAVE como 0; além disso, XSAVE salva a configuração inicial do componente de estado (as outras instruções não salvam o componente de estado i). Alternativamente, o KVM poderia sempre fazer XRSTOR com XFD=0, por exemplo, usando um XFD constante baseado no conjunto de funcionalidades habilitadas ao fazer XSAVE para um struct fpu_guest. No entanto, ter XSTATE_BV[i]=1 para funcionalidades desativadas por XFD só pode acontecer no caso de interrupção acima, ou em cenários semelhantes envolvendo preempção em kernels preemptíveis, porque a chamada de fpu_swap_kvm_fpstate() a save_fpregs_to_fpstate() salva o estado FPU de saída com o XFD atual; e isso é (em todos exceto o primeiro WRMSR para XFD) o XFD do convidado. Portanto, XFD só pode ficar fora de sincronia com XSTATE_BV no caso de interrupção acima, ou em cenários semelhantes envolvendo preempção em kernels preemptíveis, e podemos considerá-lo (de facto) parte do ABI do KVM que KVM_GET_XSAVE retorna XSTATE_BV[i]=0 para funcionalidades desativadas por XFD. [Mover clea ---truncado---