cbcvebase.
CVE-2025-21991
published 2025-04-02

CVE-2025-21991: 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…

PriorityP338high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.19%
9.5th percentile
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. ]

Affected

44 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.133-1 (bookworm)linux 6.1.133-1 (bookworm)
debianlinux-6.1< linux 6.1.133-1 (bookworm)linux 6.1.133-1 (bookworm)
linuxlinux
linuxlinux
linuxlinux
linuxlinux
linuxlinux>= 4.14.308 < 4.154.15
linuxlinux>= 4.19.276 < 4.204.20
linuxlinux>= 44a44b57e88f311c1415be1f567c50050913c149 < 985a536e04bbfffb1770df43c6470f635a6b1073985a536e04bbfffb1770df43c6470f635a6b1073
linuxlinux>= 5.10.173 < 5.10.2365.10.236
linuxlinux>= 5.15.99 < 5.15.1805.15.180
linuxlinux>= 5.4.235 < 5.4.2925.4.292
linuxlinux>= 6.1.16 < 6.1.1326.1.132
linuxlinux>= 6.2.3 < 6.36.3
linuxlinux>= 7ff6edf4fef38ab404ee7861f257e28eaaeed35f < e686349cc19e800dac8971929089ba5ff59abfb0e686349cc19e800dac8971929089ba5ff59abfb0
linuxlinux>= 7ff6edf4fef38ab404ee7861f257e28eaaeed35f < 488ffc0cac38f203979f83634236ee53251ce593488ffc0cac38f203979f83634236ee53251ce593
linuxlinux>= 7ff6edf4fef38ab404ee7861f257e28eaaeed35f < 5ac295dfccb5b015493f86694fa13a0dde4d36655ac295dfccb5b015493f86694fa13a0dde4d3665
linuxlinux>= 7ff6edf4fef38ab404ee7861f257e28eaaeed35f < e3e89178a9f4a80092578af3ff3c8478f9187d59e3e89178a9f4a80092578af3ff3c8478f9187d59
linuxlinux>= 979e197968a1e8f09bf0d706801dba4432f85ab3 < d509c4731090ebd9bbdb72c70a2d70003ae81f4fd509c4731090ebd9bbdb72c70a2d70003ae81f4f
linuxlinux>= be2710deaed3ab1402379a2ede30a3754fe6767a < 18b5d857c6496b78ead2fd10001b81ae32d30cac18b5d857c6496b78ead2fd10001b81ae32d30cac
linuxlinux>= d576547f489c935b9897d4acf8beee3325dea8a5 < ec52240622c4d218d0240079b7c1d3ec2328a9f4ec52240622c4d218d0240079b7c1d3ec2328a9f4
linuxlinux_kernel
linuxlinux_kernel>= 0 < 5.10.237-15.10.237-1
linuxlinux_kernel>= 0 < 6.1.133-16.1.133-1
linuxlinux_kernel>= 0 < 6.12.20-16.12.20-1

CVSS provenance

nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv8.8HIGH
vendor_ubuntu8.8HIGH
vendor_debian7.8HIGH
vendor_msrc7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.