Nessus detected vulnerability in the Brocade OVA base image (CVE-2025-21991)
36804
28 January 2026
27 January 2026
CLOSED
MEDIUM
7.8 High -- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2025-21991
|
Brocade Security Advisory ID |
BSA-2026-3251 |
|
Component |
Linux |
|
|
|
Summary
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.
Products Affected
- Brocade SANnav OVA versions before 2.4.0b
- Brocade ASCG OVA versions before 3.3.0a
Products Not Affected
- Brocade FabricOS
[VEX Justification: Vulnerable_code_not_present] - Brocade SANnav standard versions
[VEX Justification: Component_not_present] - Brocade ASCG standard versions
[VEX Justification: Component_not_present]
Solution
- Solution provided in Brocade ASCG OVA version 3.3.0a
- Solution provided in Brocade SANnav OVA versions 2.4.0b and 3.0.0
- SANnav base OS Security update also provided in the sannav_ova_8x_os OVA patch which can be applied to all SANnav OVA releases 2.3.0 through 2.4.0x
- SANnav base OS Security update also provided in the sannav_ova_8x_os OVA patch which can be applied to all SANnav OVA releases 2.3.0 through 2.4.0a
Revision History
|
Version |
Change |
Date |
|
1.0 |
Initial Publication |
January 27, 2026 |
Disclaimer
THIS DOCUMENT IS PROVIDED ON AN AS-IS BASIS SOLELY FOR INFORMATIONAL PURPOSES AND DOES NOT IMPLY ANY KIND OF GUARANTY OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. YOUR USE OF THE INFORMATION CONTAINED HEREIN IS AT YOUR OWN RISK. ALL INFORMATION PROVIDED HEREIN IS BASED ON BROCADE'S CURRENT KNOWLEDGE AND UNDERSTANDING OF THE VULNERABILITY AND IMPACT TO BROCADE HARDWARE AND SOFTWARE PRODUCTS. BROCADE RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.