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. ]
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4178-1 | linux security update |
Debian DLA |
DLA-4193-1 | linux-6.1 security update |
Debian DSA |
DSA-5900-1 | linux security update |
EUVD |
EUVD-2025-9538 | 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. ] |
Ubuntu USN |
USN-7585-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7585-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7585-3 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7585-4 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7585-5 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7585-6 | Linux kernel (BlueField) vulnerabilities |
Ubuntu USN |
USN-7585-7 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7591-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7591-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-7591-3 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7591-4 | Linux kernel (AWS) vulnerabilities |
Ubuntu USN |
USN-7591-5 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-7591-6 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7592-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7593-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7597-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7597-2 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-7598-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7602-1 | Linux kernel (Xilinx ZynqMP) vulnerabilities |
Ubuntu USN |
USN-7605-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7605-2 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-7606-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-7628-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7640-1 | Linux kernel (IoT) vulnerabilities |
Ubuntu USN |
USN-7655-1 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-7764-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7764-2 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7765-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-7766-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7767-1 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7767-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7779-1 | Linux kernel (IBM) vulnerabilities |
Ubuntu USN |
USN-7790-1 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7800-1 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
Ubuntu USN |
USN-7801-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7802-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7801-2 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-7809-1 | Linux kernel (Azure, N-Series) vulnerabilities |
Ubuntu USN |
USN-7801-3 | Linux kernel (Oracle) vulnerabilities |
Mon, 03 Nov 2025 20:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Wed, 01 Oct 2025 18:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Mon, 07 Jul 2025 15:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Redhat
Redhat enterprise Linux |
|
| CPEs | cpe:/o:redhat:enterprise_linux:10.0 | |
| Vendors & Products |
Redhat
Redhat enterprise Linux |
Thu, 10 Apr 2025 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-787 |
Thu, 10 Apr 2025 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux linux Kernel |
|
| Weaknesses | CWE-129 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc6:*:*:*:*:*:* |
|
| Vendors & Products |
Linux
Linux linux Kernel |
|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Thu, 10 Apr 2025 13:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Thu, 03 Apr 2025 02:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Wed, 02 Apr 2025 13:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. ] | |
| Title | x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes | |
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-11T21:10:31.756Z
Reserved: 2024-12-29T08:45:45.800Z
Link: CVE-2025-21991
Updated: 2025-10-01T14:39:04.408Z
Status : Modified
Published: 2025-04-02T13:15:43.670
Modified: 2025-11-03T20:17:34.873
Link: CVE-2025-21991
OpenCVE Enrichment
No data.
Debian DLA
Debian DSA
EUVD
Ubuntu USN