x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.1.84, 6.6.24, 6.7.12, 6.8.3
- CVEs
- CVE-2024-35801
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 11:53 UTC · Revision 1
Source evidence
x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
core-osv · Original sourcePublished 17 May 2024, 13:23 UTC
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
osv:CVE-2024-35801
Kernel
Fixed versions: 6.1.84, 6.6.24, 6.7.12, 6.8.3
Complete source record
{
"id": "eef2139fddbc0a3a52f536df1995e4062f0d0c3f4ea7dfa1b4a75a3abea8d6a2",
"url": "https://osv.dev/vulnerability/CVE-2024-35801",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD",
"summary": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 (\"x86/fpu: Update XFD state where required\") and commit 8bf26758ca96 (\"x86/fpu: Add XFD state to fpstate\") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.",
"evidence": "osv:CVE-2024-35801",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.1.84",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.24",
"evidence": "/affected/1/ranges"
},
{
"value": "6.7.12",
"evidence": "/affected/1/ranges"
},
{
"value": "6.8.3",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2024-35801",
"aliases": [
"CVE-2024-35801"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "672365477ae8afca5a1cca98c1deb733235e4525"
},
{
"fixed": "21c7c00dae55cb0e3810d5f9506b58f68475d41d"
},
{
"fixed": "1acbca933313aa866e39996904c9aca4d435c4cd"
},
{
"fixed": "92b0f04e937665bde5768f3fcc622dcce44413d8"
},
{
"fixed": "b61e3b7055ac6edee4be071c52f48c26472d2624"
},
{
"fixed": "10e4b5166df9ff7a2d5316138ca668b42d004422"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-35801.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.84"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.24"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.7.12"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.8.0"
},
{
"fixed": "6.8.3"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-35801.json"
}
}
],
"modified": "2026-10-28T02:30:34.988438906Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422",
"https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd",
"https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d",
"https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8",
"https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/35xxx/CVE-2024-35801.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-35801",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/35xxx/CVE-2024-35801.json"
}
},
"related_cves": [
{
"value": "CVE-2024-35801",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 502183,
"published_at": "2024-05-17T13:23:10.83+00:00"
}