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, loadmicrocodeamd() 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): - cpumaskofnode(nid) is 0 - cpumaskfirst(0) is CONFIGNRCPUS - cpudata(CONFIGNRCPUS) 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 CONFIGUBSANBOUNDS=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: dumpstack _ubsanhandleoutofbounds loadmicrocodeamd requestmicrocodeamd reloadstore kernfsfopwriteiter vfswrite ksyswrite dosyscall64 entrySYSCALL64afterhwframe

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