CVE-2026-23005
x86/fpu: Azzerare XSTATE_BV[i] nello stato XSAVE dell'ospite ogni volta che XFD[i]=1
- Pubblicato
- 25 gen 2026
- Aggiornato
- 8 set 2026
- Assegnazione CNA
- Linux
- Evidenza osservata
- 6 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HBasso · prossimi 30 giorni
- Percentile
- 11,1%
- Data del modello
- 21 set 2026
L'EPSS è una stima statistica, non una certezza o una misura di impatto. Combinalo con CVSS, stato KEV, esposizione e ambiente.
Riepilogo
Nel kernel Linux è stata risolta la seguente vulnerabilità: x86/fpu: Azzera XSTATE_BV[i] nello stato XSAVE dell'ospite ogni volta che XFD[i]=1 Quando si carica lo stato XSAVE dell'ospite tramite KVM_SET_XSAVE, e quando si aggiorna XFD in risposta a una WRMSR dell'ospite, azzerare le funzionalità disabilitate da XFD in XSTATE_BV salvato (o da ripristinare) per garantire che KVM non tenti di caricare lo stato per funzionalità disabilitate tramite l'XFD dell'ospite. Poiché il kernel esegue XRSTOR con l'XFD dell'ospite, salvare XSTATE_BV[i]=1 con XFD[i]=1 causerà un #NM da parte di XRSTOR e il panic del kernel. Ad esempio, se fpu_update_guest_xfd() imposta XFD senza azzerare 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 ]--- Questo può accadere se l'ospite esegue WRMSR(MSR_IA32_XFD) per impostare XFD[18] = 1, e un IRQ dell'host attiva kernel_fpu_begin() prima della chiamata a fpu_update_guest_xfd() da parte del gestore di vmexit. e se lo spazio utente inserisce XSTATE_BV[i]=1 tramite 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 ]--- Il nuovo comportamento è coerente con l'architettura AMX. Secondo l'SDM di Intel, XSAVE salva XSTATE_BV come '0' per i componenti disabilitati tramite XFD (e XSAVE non compattato salva la configurazione iniziale del componente di stato): Se XSAVE, XSAVEC, XSAVEOPT o XSAVES sta salvando il componente di stato i, l'istruzione non genera #NM quando XCR0[i] = IA32_XFD[i] = 1; invece, opera come se XINUSE[i] = 0 (e il componente di stato fosse nel suo stato iniziale): salva il bit i del campo XSTATE_BV dell'header XSAVE come 0; in aggiunta, XSAVE salva la configurazione iniziale del componente di stato (le altre istruzioni non salvano il componente di stato i). In alternativa, KVM potrebbe sempre eseguire XRSTOR con XFD=0, ad esempio utilizzando un XFD costante basato sull'insieme di funzionalità abilitate quando si esegue XSAVE per una struct fpu_guest. Tuttavia, avere XSTATE_BV[i]=1 per funzionalità disabilitate da XFD può accadere solo nel caso di interruzione sopra descritto, o in scenari simili che coinvolgono la preemption su kernel preemptibili, perché la chiamata a save_fpregs_to_fpstate() di fpu_swap_kvm_fpstate() salva lo stato FPU in uscita con l'XFD corrente; e questo è (su tutte le WRMSR a XFD tranne la prima) l'XFD dell'ospite. Pertanto, XFD può andare fuori sincronia con XSTATE_BV solo nel caso di interruzione sopra descritto, o in scenari simili che coinvolgono la preemption su kernel preemptibili, e possiamo considerarlo (di fatto) parte dell'ABI KVM che KVM_GET_XSAVE restituisce XSTATE_BV[i]=0 per le funzionalità disabilitate da XFD. [Sposta clea ---troncato---
Utilizzo responsabile
Utilizza le informazioni sulla vulnerabilità solo sui sistemi che possiedi o che sei autorizzato a testare. Kitploit si collega ai metadati della ricerca pubblica e non memorizza codici exploit o payload dannosi.