| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2025040257-CVE-2025-21991-6aae@gregkh> Date: Wed, 2 Apr 2025 13:51:58 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: CVE-2025-21991: x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes 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. ] The Linux kernel CVE team has assigned CVE-2025-21991 to this issue. Affected and fixed versions =========================== Issue introduced in 6.1.16 with commit d576547f489c935b9897d4acf8beee3325dea8a5 and fixed in 6.1.132 with commit ec52240622c4d218d0240079b7c1d3ec2328a9f4 Issue introduced in 6.3 with commit 7ff6edf4fef38ab404ee7861f257e28eaaeed35f and fixed in 6.6.84 with commit e686349cc19e800dac8971929089ba5ff59abfb0 Issue introduced in 6.3 with commit 7ff6edf4fef38ab404ee7861f257e28eaaeed35f and fixed in 6.12.20 with commit 488ffc0cac38f203979f83634236ee53251ce593 Issue introduced in 6.3 with commit 7ff6edf4fef38ab404ee7861f257e28eaaeed35f and fixed in 6.13.8 with commit 5ac295dfccb5b015493f86694fa13a0dde4d3665 Issue introduced in 6.3 with commit 7ff6edf4fef38ab404ee7861f257e28eaaeed35f and fixed in 6.14 with commit e3e89178a9f4a80092578af3ff3c8478f9187d59 Issue introduced in 4.14.308 with commit d6353e2fc12c5b8f00f86efa30ed73d2da2f77be Issue introduced in 4.19.276 with commit 1b1e0eb1d2971a686b9f7bdc146115bcefcbb960 Issue introduced in 5.4.235 with commit 979e197968a1e8f09bf0d706801dba4432f85ab3 Issue introduced in 5.10.173 with commit 44a44b57e88f311c1415be1f567c50050913c149 Issue introduced in 5.15.99 with commit be2710deaed3ab1402379a2ede30a3754fe6767a Issue introduced in 6.2.3 with commit eaf5dea1eb8c2928554b3ca717575cbe232b843c Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2025-21991 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: arch/x86/kernel/cpu/microcode/amd.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/ec52240622c4d218d0240079b7c1d3ec2328a9f4 https://git.kernel.org/stable/c/e686349cc19e800dac8971929089ba5ff59abfb0 https://git.kernel.org/stable/c/488ffc0cac38f203979f83634236ee53251ce593 https://git.kernel.org/stable/c/5ac295dfccb5b015493f86694fa13a0dde4d3665 https://git.kernel.org/stable/c/e3e89178a9f4a80092578af3ff3c8478f9187d59
Powered by blists - more mailing lists