CVE-2026-74384: nvme-multipath: fix flex array size in struct nvme_ns_head

In the Linux kernel, the following vulnerability has been resolved:

nvme-multipath: fix flex array size in struct nvmenshead

struct nvmenshead contains a flexible array member, currentpath[], which is indexed using the NUMA node ID: head->currentpath[numanodeid()]

The structure is currently allocated as: size = sizeof(struct nvmenshead) + (numpossiblenodes() sizeof(struct nvmens )); head = kzalloc(size, GFPKERNEL);

This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. numpossiblenodes() - 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: numpossiblenodes() = 6

So memory is allocated for only 6 entries in currentpath[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->currentpath[8] or head->currentpath[252] goes out of bounds, leading to the following KASAN splat:

================================================================== BUG: KASAN: slab-out-of-bounds in nvmempathrevalidatepaths+0x22c/0x290 [nvmecore] 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 asyncrunentryfn Call Trace: [c000200037fa7510] [c0000000021c23d4] dumpstacklvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] printreport+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasanreport+0x108/0x220 [c000200037fa7740] [c0000000009fff48] asanstore8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvmempathrevalidatepaths+0x22c/0x290 [nvmecore] [c000200037fa7800] [c008000018e6556c] nvmeupdatensinfo+0x4a4/0x5e0 [nvmecore] [c000200037fa7a50] [c008000018e66270] nvmeallocns+0x6d8/0x1a70 [nvmecore] [c000200037fa7c20] [c008000018e679fc] nvmescanns+0x3f4/0x630 [nvmecore] [c000200037fa7d10] [c00000000031f22c] asyncrunentryfn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] processonework+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] workerthread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] startkernelthread+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 nrnodeids instead of numpossiblenodes(). Since nrnodeids represents the maximum possible NUMA node IDs, indexing currentpath[] using numanodeid() becomes safe even on systems with sparse node IDs.