Amazon Linux AMI: CVE-2025-21991: Security patch for kernel (ALAS-2025-1973)

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