{"id":"DEBIAN-CVE-2025-21991","details":"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. ]","modified":"2026-09-01T16:06:10.634674710Z","published":"2025-04-02T13:15:43.670Z","upstream":["CVE-2025-21991"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2025-21991"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.133-1"}]}],"versions":["6.1.106-1","6.1.106-2","6.1.106-3","6.1.112-1","6.1.115-1","6.1.119-1","6.1.123-1","6.1.124-1","6.1.128-1","6.1.129-1","6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1","6.1.94-1~bpo11+1","6.1.98-1","6.1.99-1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-21991.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.20-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-21991.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.20-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2025-21991.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}