CVE-2026-23005 (GCVE-0-2026-23005)
Vulnerability from cvelistv5 – Published: 2026-01-25 14:36 – Updated: 2026-01-25 14:36
VLAI?
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, 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---
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Affected:
820a6ee944e74e57255ac2e90916ecdaade57b95 , < f577508cc8a0adb8b4ebe9480bba7683b6149930
(git)
Affected: 820a6ee944e74e57255ac2e90916ecdaade57b95 , < eea6f395ca502c4528314c8112da9b5d65f685eb (git) Affected: 820a6ee944e74e57255ac2e90916ecdaade57b95 , < b45f721775947a84996deb5c661602254ce25ce6 (git) |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/x86/kernel/fpu/core.c",
"arch/x86/kvm/x86.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f577508cc8a0adb8b4ebe9480bba7683b6149930",
"status": "affected",
"version": "820a6ee944e74e57255ac2e90916ecdaade57b95",
"versionType": "git"
},
{
"lessThan": "eea6f395ca502c4528314c8112da9b5d65f685eb",
"status": "affected",
"version": "820a6ee944e74e57255ac2e90916ecdaade57b95",
"versionType": "git"
},
{
"lessThan": "b45f721775947a84996deb5c661602254ce25ce6",
"status": "affected",
"version": "820a6ee944e74e57255ac2e90916ecdaade57b95",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/x86/kernel/fpu/core.c",
"arch/x86/kvm/x86.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.17"
},
{
"lessThan": "5.17",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.67",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19-rc6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.67",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.7",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19-rc6",
"versionStartIncluding": "5.17",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn\u0027t attempt to load state for\nfeatures that are disabled via the guest\u0027s XFD. Because the kernel\nexecutes XRSTOR with the guest\u0027s 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 \u003cTASK\u003e\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 \u003c/TASK\u003e\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\u0027s\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 \u003cTASK\u003e\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 \u003c/TASK\u003e\n ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture. Per Intel\u0027s SDM,\nXSAVE saves XSTATE_BV as \u00270\u0027 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()\u0027s 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---"
}
],
"providerMetadata": {
"dateUpdated": "2026-01-25T14:36:19.021Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/f577508cc8a0adb8b4ebe9480bba7683b6149930"
},
{
"url": "https://git.kernel.org/stable/c/eea6f395ca502c4528314c8112da9b5d65f685eb"
},
{
"url": "https://git.kernel.org/stable/c/b45f721775947a84996deb5c661602254ce25ce6"
}
],
"title": "x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23005",
"datePublished": "2026-01-25T14:36:19.021Z",
"dateReserved": "2026-01-13T15:37:45.939Z",
"dateUpdated": "2026-01-25T14:36:19.021Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-23005\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-01-25T15:15:55.377\",\"lastModified\":\"2026-01-26T15:03:33.357\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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, clear XFD-disabled features in the saved (or to\\nbe restored) XSTATE_BV to ensure KVM doesn\u0027t attempt to load state for\\nfeatures that are disabled via the guest\u0027s XFD. Because the kernel\\nexecutes XRSTOR with the guest\u0027s 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 \u003cTASK\u003e\\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 \u003c/TASK\u003e\\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\u0027s\\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 \u003cTASK\u003e\\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 \u003c/TASK\u003e\\n ---[ end trace 0000000000000000 ]---\\n\\nThe new behavior is consistent with the AMX architecture. Per Intel\u0027s SDM,\\nXSAVE saves XSTATE_BV as \u00270\u0027 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()\u0027s 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---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/b45f721775947a84996deb5c661602254ce25ce6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/eea6f395ca502c4528314c8112da9b5d65f685eb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f577508cc8a0adb8b4ebe9480bba7683b6149930\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…