Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-15T06:22:40.270Z",
  "pubdate": "2026-08-15T06:22:40.270Z",
  "executiveSummary": "An out-of-bounds memory access vulnerability exists in the Linux kernel nvme-multipath subsystem, specifically within the struct nvme_ns_head memory allocation logic.\nThe vulnerability is classified as a heap out-of-bounds write/read issue, stemming from improper array sizing when handling NUMA node identifiers.\nThe flaw affects systems running the Linux kernel with NVMe multipathing enabled, particularly architectures such as powerpc where NUMA node IDs can be sparse and non-sequential.\nIf triggered, an attacker or standard system workload can cause kernel memory corruption via KASAN-detected slab out-of-bounds events during path revalidation, potentially resulting in kernel panics, denial of service, or unpredictable system behavior.\nExploitation requires local execution context or kernel-level code paths triggered during NVMe namespace scans and path updates, without necessitating specialized remote attacker capabilities or complex authentication bypasses beyond local execution.",
  "technicalDetails": "The root cause of the vulnerability lies in the incorrect assumption that NUMA node IDs are always sequential and densely packed from zero up to num_possible_nodes() minus one.\nThe vulnerable component is struct nvme_ns_head in the nvme-multipath subsystem, which contains a flexible array member named current_path[] indexed directly by the return value of numa_node_id().\nDuring memory allocation, the kernel previously sized the structure using size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); followed by a kzalloc() call.\nOn architectures like powerpc, NUMA node IDs can be sparse and non-sequential (e.g., node IDs such as 0, 8, 252, 253, 254, and 255 while num_possible_nodes() returns a count of 6).\nConsequently, memory allocated for current_path[] is insufficient to hold entries matching higher or non-sequential node IDs.\nWhen functions such as nvme_mpath_revalidate_paths() attempt to access or write to indices like head->current_path[8] or head->current_path[252], the execution flows outside the boundaries of the allocated slab cache object (kmalloc-rnd-15-2k).\nThis triggers a slab-out-of-bounds write as identified by KernelAddressSanitizer (KASAN) splats during tasks such as nvme_update_ns_info and nvme_alloc_ns executed via async workqueues.\nThe attack flow proceeds as follows: 1) The kernel initiates an asynchronous NVMe namespace scan during storage device initialization or revalidation. 2) The subsystem allocates memory for struct nvme_ns_head using the flawed num_possible_nodes() calculation. 3) The kernel queries the current NUMA node ID, which evaluates to a sparse, high-value integer due to architecture-specific topology. 4) The subsystem attempts to store a pointer into current_path[] using this high-value index. 5) The memory write lands outside the allocated heap buffer, corrupting adjacent slab memory and triggering a kernel safety crash."
}