CVE-2026-23005
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-25

Last updated on: 2026-03-25

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel. E.g. if fpu_update_guest_xfd() sets XFD without clearing 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 ]--- This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd(). and if userspace stuffs 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 ]--- The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i). Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD. Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features. [Move clea ---truncated---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-25
Last Modified
2026-03-25
Generated
2026-05-07
AI Q&A
2026-01-25
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23005
Affected Vendors & Products
Showing 13 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.17
linux linux_kernel From 6.13 (inc) to 6.18.7 (exc)
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.2 (inc) to 6.6.122 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.67 (exc)
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 5.17.1 (inc) to 6.1.162 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel's handling of the XSAVE state in virtualized environments using KVM. Specifically, when loading guest XSAVE state or updating the XFD register, the kernel failed to clear certain bits (XSTATE_BV[i]) corresponding to features disabled by the guest's XFD. This mismatch can cause the kernel to attempt to load state for disabled features, leading to a device-not-available (#NM) exception and kernel panic. The issue arises in scenarios such as when a guest executes WRMSR to set XFD bits and an interrupt triggers kernel_fpu_begin() before the update completes, or when userspace sets XSTATE_BV bits improperly via KVM_SET_XSAVE. The fix ensures that XSTATE_BV bits are cleared for features disabled by XFD, preventing the kernel from loading invalid state and avoiding crashes.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to panic and crash when running virtual machines under KVM, due to improper handling of floating-point unit (FPU) state related to disabled features. Such kernel panics can lead to denial of service for the affected virtual machines or hosts, potentially disrupting services and causing system instability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as kernel panics with warnings related to exc_device_not_available and XRSTOR #NM errors in the kernel logs. Detection involves monitoring the system kernel logs for messages similar to: "WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110" and call traces involving kvm and fpu functions. You can check the kernel logs using commands like: - dmesg | grep exc_device_not_available - journalctl -k | grep exc_device_not_available These commands help identify if the kernel has encountered the specific fault caused by this vulnerability during guest XSAVE state loading or WRMSR operations.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is resolved. The fix ensures that when loading guest XSAVE state or updating XFD, the kernel clears XFD-disabled features in the saved XSTATE_BV to prevent kernel panics. Until the kernel is updated, avoid workloads or guest operations that trigger WRMSR(MSR_IA32_XFD) with XFD[18]=1 or use KVM_SET_XSAVE with inconsistent XSTATE_BV settings. Monitoring and restricting such guest operations can reduce the risk of kernel panics caused by this issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart