CVE-2026-23005

Résumé

Dans le noyau Linux, la vulnérabilité suivante a été résolue : x86/fpu : Effacer XSTATE_BV[i] dans l'état XSAVE invité chaque fois que XFD[i]=1 Lors du chargement de l'état XSAVE invité via KVM_SET_XSAVE, et lors de la mise à jour de XFD en réponse à un WRMSR invité, effacez les fonctionnalités désactivées par XFD dans XSTATE_BV enregistré (ou à restaurer) pour garantir que KVM ne tente pas de charger l'état des fonctionnalités désactivées via le XFD de l'invité. Étant donné que le noyau exécute XRSTOR avec le XFD de l'invité, enregistrer XSTATE_BV[i]=1 avec XFD[i]=1 provoquera un #NM de XRSTOR et un panic du noyau. Par exemple, si fpu_update_guest_xfd() définit XFD sans effacer 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 ]--- Cela peut se produire si l'invité exécute WRMSR(MSR_IA32_XFD) pour définir XFD[18] = 1, et qu'une IRQ hôte déclenche kernel_fpu_begin() avant l'appel de fpu_update_guest_xfd() par le gestionnaire de vmexit. et si l'espace utilisateur insère 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 ]--- Le nouveau comportement est cohérent avec l'architecture AMX. Selon le SDM d'Intel, XSAVE enregistre XSTATE_BV comme « 0 » pour les composants désactivés via XFD (et XSAVE non compacté enregistre la configuration initiale du composant d'état) : Si XSAVE, XSAVEC, XSAVEOPT ou XSAVES enregistre le composant d'état i, l'instruction ne génère pas de #NM lorsque XCR0[i] = IA32_XFD[i] = 1 ; au lieu de cela, elle fonctionne comme si XINUSE[i] = 0 (et que le composant d'état était dans son état initial) : elle enregistre le bit i du champ XSTATE_BV de l'en-tête XSAVE comme 0 ; en outre, XSAVE enregistre la configuration initiale du composant d'état (les autres instructions n'enregistrent pas le composant d'état i). Alternativement, KVM pourrait toujours effectuer XRSTOR avec XFD=0, par exemple en utilisant un XFD constant basé sur l'ensemble des fonctionnalités activées lors du XSAVE pour un struct fpu_guest. Cependant, avoir XSTATE_BV[i]=1 pour des fonctionnalités désactivées par XFD ne peut se produire que dans le cas d'interruption ci-dessus, ou dans des scénarios similaires impliquant la préemption sur des noyaux préemptibles, car l'appel de save_fpregs_to_fpstate() par fpu_swap_kvm_fpstate() enregistre l'état FPU sortant avec le XFD actuel ; et cela est (sur tous les WRMSR à XFD sauf le premier) le XFD de l'invité. Par conséquent, XFD ne peut se désynchroniser de XSTATE_BV que dans le cas d'interruption ci-dessus, ou dans des scénarios similaires impliquant la préemption sur des noyaux préemptibles, et nous pouvons le considérer (de facto) comme faisant partie de l'ABI KVM que KVM_GET_XSAVE renvoie XSTATE_BV[i]=0 pour les fonctionnalités désactivées par XFD. [Déplacer clea ---tronqué---