GHSA-VP9X-33X6-JVVM
Vulnerability from github – Published: 2025-04-02 15:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes
Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their CPU masks and unconditionally accesses per-CPU data for the first CPU of each mask.
According to Documentation/admin-guide/mm/numaperf.rst:
"Some memory may share the same node as a CPU, and others are provided as memory only nodes."
Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".
On a machine with far memory (and therefore CPU-less NUMA nodes): - cpumask_of_node(nid) is 0 - cpumask_first(0) is CONFIG_NR_CPUS - cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of bounds
This does not have any security implications since flashing microcode is a privileged operation but I believe this has reliability implications by potentially corrupting memory while flashing a microcode update.
When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes a microcode update. I get the following splat:
UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe
Change the loop to go over only NUMA nodes which have CPUs before determining whether the first CPU on the respective node needs microcode update.
[ bp: Massage commit message, fix typo. ]
{
"affected": [],
"aliases": [
"CVE-2025-21991"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-02T13:15:43Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes\n\nCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves their\nCPU masks and unconditionally accesses per-CPU data for the first CPU of each\nmask.\n\nAccording to Documentation/admin-guide/mm/numaperf.rst:\n\n \"Some memory may share the same node as a CPU, and others are provided as\n memory only nodes.\"\n\nTherefore, some node CPU masks may be empty and wouldn\u0027t have a \"first CPU\".\n\nOn a machine with far memory (and therefore CPU-less NUMA nodes):\n- cpumask_of_node(nid) is 0\n- cpumask_first(0) is CONFIG_NR_CPUS\n- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an\n index that is 1 out of bounds\n\nThis does not have any security implications since flashing microcode is\na privileged operation but I believe this has reliability implications by\npotentially corrupting memory while flashing a microcode update.\n\nWhen booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes\na microcode update. I get the following splat:\n\n UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y\n index 512 is out of range for type \u0027unsigned long[512]\u0027\n [...]\n Call Trace:\n dump_stack\n __ubsan_handle_out_of_bounds\n load_microcode_amd\n request_microcode_amd\n reload_store\n kernfs_fop_write_iter\n vfs_write\n ksys_write\n do_syscall_64\n entry_SYSCALL_64_after_hwframe\n\nChange the loop to go over only NUMA nodes which have CPUs before determining\nwhether the first CPU on the respective node needs microcode update.\n\n [ bp: Massage commit message, fix typo. ]",
"id": "GHSA-vp9x-33x6-jvvm",
"modified": "2025-11-03T21:33:28Z",
"published": "2025-04-02T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21991"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18b5d857c6496b78ead2fd10001b81ae32d30cac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/488ffc0cac38f203979f83634236ee53251ce593"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ac295dfccb5b015493f86694fa13a0dde4d3665"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/985a536e04bbfffb1770df43c6470f635a6b1073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d509c4731090ebd9bbdb72c70a2d70003ae81f4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3e89178a9f4a80092578af3ff3c8478f9187d59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e686349cc19e800dac8971929089ba5ff59abfb0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec52240622c4d218d0240079b7c1d3ec2328a9f4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.