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. ]
Metrics
Affected Vendors & Products
| 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 |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
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: 2025-11-03T19:40:28.243Z
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