DEBIAN-CVE-2026-74384

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 numanode_id() becomes safe even on systems with sparse node IDs.