CVE-2026-74384 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: fix flex array size in struct nvme_ns_head
struct nvme_ns_head contains a flexible array member, current_path[],
which is indexed using the NUMA node ID: head->current_path[numa_node_id()]
The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL);
This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc.
On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s):
That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6
So memory is allocated for only 6 entries in current_path[]. However,
the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or
head->current_path[252]
goes out of bounds, leading to the following KASAN splat:
================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core]
Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997
CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable)
[c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c
[c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220
[c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120
[c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core]
[c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core]
[c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core]
[c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core]
[c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0
[c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10
[c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640
[c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290
[c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18
Allocated by task 1997 on cpu 1 at 35.928317s:
The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8)
The buggy address belongs to the physical page:
Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ==================================================================
Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id()
becomes safe even on systems with sparse node IDs.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability resides in the Linux kernel's NVMe multipath implementation where a flexible array member within the struct nvme_ns_head structure is improperly sized leading to out-of-bounds memory access. This flaw specifically impacts systems utilizing Non-Uniform Memory Access (NUMA) architectures where NUMA node IDs are not sequentially packed from zero, as is commonly assumed in typical allocations. The structure contains a flexible array current_path[] indexed by NUMA node ID through the expression head->current_path[numa_node_id()], which creates a direct mapping between the allocated memory space and potentially non-contiguous NUMA identifiers.
The core technical issue arises from how memory allocation is performed for struct nvme_ns_head. Initially, the kernel computes size as sizeof(struct nvme_ns_head) plus (num_possible_nodes() sizeof(struct nvme_ns )), assuming that NUMA node IDs will be densely packed starting from zero up to num_possible_nodes() - 1. However, certain architectures like powerpc may present sparse NUMA node configurations where actual node IDs can be scattered across large numerical ranges such as 0, 8, 252, 253, 254, and 255. When these systems attempt to access current_path[8] or current_path[252], they exceed the bounds of memory allocated for only num_possible_nodes() entries.
This memory corruption manifests as a KASAN (Kernel Address Sanitizer) error during nvme_mpath_revalidate_paths function execution, where a write operation of size 8 occurs beyond the allocated slab boundaries. The error trace demonstrates that memory was allocated within kmalloc-rnd-15-2k cache with a region size of 2048 bytes, but accesses to addresses like c00020003bda35b8 occur outside this boundary, resulting in a slab-out-of-bounds condition. The vulnerability directly maps to CWE-129: Improper Validation of Array Index and follows ATT&CK technique T1068: Exploitation for Privilege Escalation through kernel memory corruption.
The fix implemented involves changing the allocation mechanism from using num_possible_nodes() to nr_node_ids, which represents the maximum possible NUMA node ID rather than just the count of currently possible nodes. This ensures that current_path[] is allocated sufficient space to accommodate any valid NUMA node ID encountered on the system regardless of sparsity. The solution aligns with established practices for handling flexible array members in kernel code and prevents out-of-bounds memory access patterns that could lead to system instability or potential privilege escalation attacks, particularly affecting systems running powerpc architecture with sparse NUMA configurations.