CVE - CVE-2025-21991

CVE-ID
CVE-2025-21991	Learn more at National Vulnerability Database (NVD) • CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information
Description
In 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. ]
References
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.
MISC:https://git.kernel.org/stable/c/488ffc0cac38f203979f83634236ee53251ce593 URL:https://git.kernel.org/stable/c/488ffc0cac38f203979f83634236ee53251ce593 MISC:https://git.kernel.org/stable/c/5ac295dfccb5b015493f86694fa13a0dde4d3665 URL:https://git.kernel.org/stable/c/5ac295dfccb5b015493f86694fa13a0dde4d3665 MISC:https://git.kernel.org/stable/c/e3e89178a9f4a80092578af3ff3c8478f9187d59 URL:https://git.kernel.org/stable/c/e3e89178a9f4a80092578af3ff3c8478f9187d59 MISC:https://git.kernel.org/stable/c/e686349cc19e800dac8971929089ba5ff59abfb0 URL:https://git.kernel.org/stable/c/e686349cc19e800dac8971929089ba5ff59abfb0 MISC:https://git.kernel.org/stable/c/ec52240622c4d218d0240079b7c1d3ec2328a9f4 URL:https://git.kernel.org/stable/c/ec52240622c4d218d0240079b7c1d3ec2328a9f4
Assigning CNA
kernel.org
Date Record Created
20241229	Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
Phase (Legacy)
Assigned (20241229)
Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)
N/A
This is an record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.
Search CVE Using Keywords: You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select "Other" from dropdown)