CVE-2025-21991

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes<br /> <br /> Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their<br /> CPU masks and unconditionally accesses per-CPU data for the first CPU of each<br /> mask.<br /> <br /> According to Documentation/admin-guide/mm/numaperf.rst:<br /> <br /> "Some memory may share the same node as a CPU, and others are provided as<br /> memory only nodes."<br /> <br /> Therefore, some node CPU masks may be empty and wouldn&amp;#39;t have a "first CPU".<br /> <br /> On a machine with far memory (and therefore CPU-less NUMA nodes):<br /> - cpumask_of_node(nid) is 0<br /> - cpumask_first(0) is CONFIG_NR_CPUS<br /> - cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an<br /> index that is 1 out of bounds<br /> <br /> This does not have any security implications since flashing microcode is<br /> a privileged operation but I believe this has reliability implications by<br /> potentially corrupting memory while flashing a microcode update.<br /> <br /> When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes<br /> a microcode update. I get the following splat:<br /> <br /> UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y<br /> index 512 is out of range for type &amp;#39;unsigned long[512]&amp;#39;<br /> [...]<br /> Call Trace:<br /> dump_stack<br /> __ubsan_handle_out_of_bounds<br /> load_microcode_amd<br /> request_microcode_amd<br /> reload_store<br /> kernfs_fop_write_iter<br /> vfs_write<br /> ksys_write<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> Change the loop to go over only NUMA nodes which have CPUs before determining<br /> whether the first CPU on the respective node needs microcode update.<br /> <br /> [ bp: Massage commit message, fix typo. ]