{"id":"CVE-2026-23005","title":"x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < b5995c01ba53d84182ecb9492fc4d91cfe8a362d","Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < 1e2848bda819af569dfe7ab186223855e092a2cb","Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < f577508cc8a0adb8b4ebe9480bba7683b6149930","Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < eea6f395ca502c4528314c8112da9b5d65f685eb","Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < b45f721775947a84996deb5c661602254ce25ce6","Linux 5.17"],"ssvc":{"exploitation":"none","automatable":"no","technicalImpact":"partial","timestamp":"2026-06-10T20:42:31.188844Z"},"exploitAvailable":true,"published":"2026-01-25","updated":"2026-09-08","sourceUpdated":"2026-09-08T08:44:35.157Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-23005","references":[{"url":"https://git.kernel.org/stable/c/b5995c01ba53d84182ecb9492fc4d91cfe8a362d"},{"url":"https://git.kernel.org/stable/c/1e2848bda819af569dfe7ab186223855e092a2cb"},{"url":"https://git.kernel.org/stable/c/f577508cc8a0adb8b4ebe9480bba7683b6149930"},{"url":"https://git.kernel.org/stable/c/eea6f395ca502c4528314c8112da9b5d65f685eb"},{"url":"https://git.kernel.org/stable/c/b45f721775947a84996deb5c661602254ce25ce6"}],"tags":["cve.org","exploit-available"],"epss":0.00207,"epssPercentile":0.11122,"exploits":{"github":1,"githubRepos":["https://github.com/George0Papasotiriou/CVE-2026-23005-Matter-Commissioning-Code-Brute-Force-Without-Rate-Limit"],"checkedAt":"2026-09-21T15:28:29.427Z"},"ingestedAt":"2026-09-08T15:33:26.994Z","slug":"CVE-2026-23005","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn't attempt to load state for\nfeatures that are disabled via the guest's XFD.  Because the kernel\nexecutes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n  Modules linked in: kvm_intel kvm irqbypass\n  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\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   <TASK>\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   switch_fpu_return+0x4a/0xb0\n   kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n  Modules linked in: kvm_intel kvm irqbypass\n  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\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   <TASK>\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   fpu_swap_kvm_fpstate+0x6b/0x120\n   kvm_load_guest_fpu+0x30/0x80 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture.  Per Intel's SDM,\nXSAVE saves XSTATE_BV as '0' for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n  If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n  the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n  instead, it operates as if XINUSE[i] = 0 (and the state component was\n  in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n  header as 0; in addition, XSAVE saves the initial configuration of the\n  state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest.  However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\n---truncated---\n\n## Affected\n\n- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < b5995c01ba53d84182ecb9492fc4d91cfe8a362d`\n- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < 1e2848bda819af569dfe7ab186223855e092a2cb`\n- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < f577508cc8a0adb8b4ebe9480bba7683b6149930`\n- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < eea6f395ca502c4528314c8112da9b5d65f685eb`\n- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < b45f721775947a84996deb5c661602254ce25ce6`\n- `Linux 5.17`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"twilight","depthScore":15,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":12,"ransomware":0},"changes":[]}