External risk intelligence

Linux Kernel NVMe Multipath Flex Array Out-of-Bounds Access

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-74384

This vulnerability exists within the Linux kernel's NVMe multipath subsystem, specifically regarding internal memory allocation for NUMA node handling. It is a low-level kernel memory management issue that is not reachable from the network or internet, as it involves local system hardware architecture and kernel-level data structures.

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A Linux kernel vulnerability has been resolved that could lead to system instability if NUMA node IDs are not sequential. This issue, found in the nvme-multipath component, concerns how memory is allocated and accessed based on system architecture, potentially causing out-of-bounds reads or writes.

  • Kernel memory allocation issue confirmed.
  • Matters if using non-standard NUMA architectures.
  • Confirm relevance and system exposure.

Attack Path

How an attacker could exploit the issue

An attacker could cause a denial of service by triggering an out-of-bounds write within the Linux kernel's NVMe multipath component. This occurs when the system's NUMA node IDs are not sequential, leading to incorrect memory allocation for managing device paths.

  • Requires local or privileged access.
  • Triggered by operations on NUMA systems.
  • Leads to system instability or crash.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could affect the integrity of kernel memory when the Linux kernel's NVMe multipath driver incorrectly handles NUMA node IDs on certain architectures. This could occur when the system's NUMA node IDs are not sequential or densely packed, leading to out-of-bounds memory writes.

  • Kernel memory integrity.
  • Out-of-bounds memory writes.
  • System instability or crashes.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts the Linux kernel's NVMe multipath handling, specifically how it allocates memory based on NUMA node IDs. Infrastructure or platform teams responsible for the kernel's stability and hardware interaction are likely to own this issue. The first practical step is to identify all systems using the affected kernel, confirm exposure by checking NUMA configurations, and then plan remediation, potentially coordinating with hardware vendors if specific architectures are involved.

  • Infrastructure or platform teams own remediation.
  • Verify NUMA configurations and affected systems.
  • Plan coordinated updates and test.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is the Linux kernel nvme-multipath component?

The nvme-multipath component is a subsystem within the Linux kernel designed to manage multiple physical paths to Non-Volatile Memory Express (NVMe) storage devices. It ensures high availability and load balancing by managing how the system communicates with storage through different controller paths, particularly on complex systems using Non-Uniform Memory Access (NUMA) architectures.

What does CVE-2026-74384 mean?

This CVE describes an out-of-bounds memory access vulnerability. The kernel allocates a fixed-size array to track storage paths based on an assumption that NUMA node IDs are always sequential. When a system uses sparse or non-sequential node IDs, the kernel may attempt to access memory outside the allocated buffer, which can cause system crashes or memory corruption.

How is this vulnerability triggered?

The flaw is triggered when the kernel performs memory operations on NVMe path structures on hardware architectures where NUMA node IDs are sparse (not sequential). It is not triggered by external network traffic; rather, it is a consequence of how the kernel manages internal memory structures in relation to the specific, non-contiguous hardware node numbering of the host system.

Do I need to worry about this issue?

According to Halo Surface Signal, this vulnerability is very unlikely to be reachable from the network or internet. Because it is a low-level memory management issue inside the kernel, your primary concern is limited to systems with specific, non-sequential NUMA hardware configurations rather than generic network-facing exposure.

What are the first steps to address this?

Begin by identifying which of your Linux systems are running the affected kernel versions and have hardware architectures that utilize sparse NUMA node IDs. Once identified, prioritize these systems for testing and deployment of the official kernel patches provided by your distribution vendor to correct the memory allocation logic.

References