CVE-2026-23005

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1<br /> <br /> When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in<br /> response to a guest WRMSR, clear XFD-disabled features in the saved (or to<br /> be restored) XSTATE_BV to ensure KVM doesn&amp;#39;t attempt to load state for<br /> features that are disabled via the guest&amp;#39;s XFD. Because the kernel<br /> executes XRSTOR with the guest&amp;#39;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1<br /> will cause XRSTOR to #NM and panic the kernel.<br /> <br /> E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848<br /> Modules linked in: kvm_intel kvm irqbypass<br /> 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<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:exc_device_not_available+0x101/0x110<br /> Call Trace:<br /> <br /> asm_exc_device_not_available+0x1a/0x20<br /> RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90<br /> switch_fpu_return+0x4a/0xb0<br /> kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]<br /> kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x62/0x940<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,<br /> and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler&amp;#39;s<br /> call to fpu_update_guest_xfd().<br /> <br /> and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867<br /> Modules linked in: kvm_intel kvm irqbypass<br /> 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<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:exc_device_not_available+0x101/0x110<br /> Call Trace:<br /> <br /> asm_exc_device_not_available+0x1a/0x20<br /> RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90<br /> fpu_swap_kvm_fpstate+0x6b/0x120<br /> kvm_load_guest_fpu+0x30/0x80 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]<br /> kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x62/0x940<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The new behavior is consistent with the AMX architecture. Per Intel&amp;#39;s SDM,<br /> XSAVE saves XSTATE_BV as &amp;#39;0&amp;#39; for components that are disabled via XFD<br /> (and non-compacted XSAVE saves the initial configuration of the state<br /> component):<br /> <br /> If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,<br /> the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;<br /> instead, it operates as if XINUSE[i] = 0 (and the state component was<br /> in its initial state): it saves bit i of XSTATE_BV field of the XSAVE<br /> header as 0; in addition, XSAVE saves the initial configuration of the<br /> state component (the other instructions do not save state component i).<br /> <br /> Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using<br /> a constant XFD based on the set of enabled features when XSAVEing for<br /> a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled<br /> features can only happen in the above interrupt case, or in similar<br /> scenarios involving preemption on preemptible kernels, because<br /> fpu_swap_kvm_fpstate()&amp;#39;s call to save_fpregs_to_fpstate() saves the<br /> outgoing FPU state with the current XFD; and that is (on all but the<br /> first WRMSR to XFD) the guest XFD.<br /> <br /> Therefore, XFD can only go out of sync with XSTATE_BV in the above<br /> interrupt case, or in similar scenarios involving preemption on<br /> preemptible kernels, and it we can consider it (de facto) part of KVM<br /> ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.<br /> <br /> [Move clea<br /> ---truncated---