CVE-2026-23005

Resumen

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Limpiar XSTATE_BV[i] en el estado XSAVE del invitado siempre que XFD[i]=1 Al cargar el estado XSAVE del invitado mediante KVM_SET_XSAVE, y al actualizar XFD en respuesta a un WRMSR del invitado, limpiar las características deshabilitadas por XFD en el XSTATE_BV guardado (o por restaurar) para garantizar que KVM no intente cargar estado para características que están deshabilitadas a través del XFD del invitado. Debido a que el kernel ejecuta XRSTOR con el XFD del invitado, guardar XSTATE_BV[i]=1 con XFD[i]=1 hará que XRSTOR genere #NM y provoque un pánico en el kernel. Por ejemplo, si fpu_update_guest_xfd() establece XFD sin limpiar 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 ]--- Esto puede ocurrir si el invitado ejecuta WRMSR(MSR_IA32_XFD) para establecer XFD[18] = 1, y una IRQ del host activa kernel_fpu_begin() antes de la llamada del manejador de vmexit a fpu_update_guest_xfd(). y si el espacio de usuario introduce XSTATE_BV[i]=1 mediante 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 ]--- El nuevo comportamiento es consistente con la arquitectura AMX. Según el SDM de Intel, XSAVE guarda XSTATE_BV como '0' para los componentes que están deshabilitados mediante XFD (y XSAVE no compactado guarda la configuración inicial del componente de estado): Si XSAVE, XSAVEC, XSAVEOPT o XSAVES está guardando el componente de estado i, la instrucción no genera #NM cuando XCR0[i] = IA32_XFD[i] = 1; en su lugar, opera como si XINUSE[i] = 0 (y el componente de estado estuviera en su estado inicial): guarda el bit i del campo XSTATE_BV del encabezado XSAVE como 0; además, XSAVE guarda la configuración inicial del componente de estado (las otras instrucciones no guardan el componente de estado i). Alternativamente, KVM podría hacer siempre XRSTOR con XFD=0, por ejemplo, usando un XFD constante basado en el conjunto de características habilitadas al hacer XSAVE para un struct fpu_guest. Sin embargo, tener XSTATE_BV[i]=1 para características deshabilitadas por XFD solo puede ocurrir en el caso de interrupción anterior, o en escenarios similares que involucran desalojo (preemption) en kernels con desalojo habilitado, porque la llamada de fpu_swap_kvm_fpstate() a save_fpregs_to_fpstate() guarda el estado FPU saliente con el XFD actual; y ese es (en todos excepto el primer WRMSR a XFD) el XFD del invitado. Por lo tanto, XFD solo puede desincronizarse con XSTATE_BV en el caso de interrupción anterior, o en escenarios similares que involucran desalojo en kernels con desalojo habilitado, y podemos considerarlo (de facto) parte del ABI de KVM que KVM_GET_XSAVE devuelve XSTATE_BV[i]=0 para características deshabilitadas por XFD. [Mover clea ---truncado---