---
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:

  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…
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.00221
epssPercentile: 0.12942
exploits:
  github: 1
  githubRepos:
    - >-
      https://github.com/George0Papasotiriou/CVE-2026-23005-Matter-Commissioning-Code-Brute-Force-Without-Rate-Limit
  checkedAt: '2026-09-23T07:13:54.969Z'
ingestedAt: '2026-09-08T15:33:26.994Z'
---

## Overview

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---

## Affected

- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < b5995c01ba53d84182ecb9492fc4d91cfe8a362d`
- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < 1e2848bda819af569dfe7ab186223855e092a2cb`
- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < f577508cc8a0adb8b4ebe9480bba7683b6149930`
- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < eea6f395ca502c4528314c8112da9b5d65f685eb`
- `Linux >= 820a6ee944e74e57255ac2e90916ecdaade57b95 < b45f721775947a84996deb5c661602254ce25ce6`
- `Linux 5.17`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.