{"id":"CVE-2026-23005","title":"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…","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":"medium","cvss":5.5,"cvssVector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","vendor":"linux","product":"linux_kernel","affected":["linux_kernel >= 5.17.1, < 6.1.162","linux_kernel >= 6.2, < 6.6.122","linux_kernel >= 6.7, < 6.12.67","linux_kernel >= 6.13, < 6.18.7","linux_kernel = 5.17","linux_kernel = 6.19"],"patched":["linux_kernel 6.18.7"],"published":"2026-01-25","updated":"2026-10-15","sourceUpdated":"2026-10-15T02:18:39.417","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-23005","references":[{"url":"https://git.kernel.org/stable/c/1e2848bda819af569dfe7ab186223855e092a2cb","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/b45f721775947a84996deb5c661602254ce25ce6","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/b5995c01ba53d84182ecb9492fc4d91cfe8a362d","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/eea6f395ca502c4528314c8112da9b5d65f685eb","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/f577508cc8a0adb8b4ebe9480bba7683b6149930","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://cert-portal.siemens.com/productcert/html/ssa-019113.html","label":"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"},{"url":"https://cert-portal.siemens.com/productcert/html/ssa-457936.html","label":"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"}],"tags":["nvd","exploit-available","cve.org"],"epss":0.00218,"epssPercentile":0.12203,"exploits":{"github":1,"githubRepos":["https://github.com/George0Papasotiriou/CVE-2026-23005-Matter-Commissioning-Code-Brute-Force-Without-Rate-Limit"],"checkedAt":"2026-10-27T17:02:18.847Z"},"exploitAvailable":true,"ssvc":{"exploitation":"none","automatable":"no","technicalImpact":"partial","timestamp":"2026-06-10T20:42:31.188844Z"},"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_kernel >= 5.17.1, < 6.1.162`\n- `linux_kernel >= 6.2, < 6.6.122`\n- `linux_kernel >= 6.7, < 6.12.67`\n- `linux_kernel >= 6.13, < 6.18.7`\n- `linux_kernel = 5.17`\n- `linux_kernel = 6.19`\n\n## Remediation\n\nUpgrade past the affected range:\n\n- `linux_kernel 6.18.7`","depth":"twilight","depthScore":42,"depthScoreParts":{"impact":30.3,"likelihood":0,"exploitation":12,"ransomware":0},"changes":[{"seq":221597,"id":"CVE-2026-23005","ts":1792035286157,"field":"cvss","old":null,"new":"5.5"},{"seq":221596,"id":"CVE-2026-23005","ts":1792035286157,"field":"severity","old":"none","new":"medium"}]}