Skip to main content

Linux Kernel EUVDEUVD-2026-59531

| CVE-2026-74384 CRITICAL
2026-08-15 Linux GHSA-hggw-gjv7-4223
Buffer Overflow Linux
Critical
Disputed · 9.8 Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Boot host with sparse NUMA node IDs
  2. Delivery
    Kernel scans NVMe namespace
  3. Exploit
    nvme_mpath_revalidate_paths indexes current_path[node_id]
  4. Execution
    Write past flex-array allocation
  5. Impact
    Slab out-of-bounds corruption / KASAN splat

Vulnerability Assessment

Exploitation Conditions

Requires a system whose NUMA node IDs are non-contiguous/sparse (numa_node_id() can exceed num_possible_nodes()-1), as seen on some powerpc/POWER9 machines with node IDs like 0, 8, 252, 253, 254, 255; the kernel must be built with NVMe multipath and must scan/revalidate an NVMe namespace, which invokes nvme_mpath_revalidate_paths and indexes current_path[]. Limiting factors that sharply constrain real-world risk: it is not remotely reachable, needs no attacker input but also gives the attacker no input channel, does not manifest on the common case of dense NUMA node IDs (most x86 servers), and depends on specific hardware/firmware topology plus the NVMe-multipath configuration.
Impact

The signals conflict sharply and the raw score is misleading. The NVD CVSS of 9.8 with AV:N/AC:L/PR:N/UI:N implies trivial remote unauthenticated compromise, but the description makes clear this is a local, hardware-topology-dependent memory-safety bug triggered by the kernel itself during NVMe namespace scanning - there is no network vector and no attacker-supplied input in the described path, so the network/critical rating is not supportable from the evidence and should be treated as an automated over-scoring artifact common to bulk kernel CVEs. EPSS (0.18%, 7th percentile), the absence of any KEV listing, and no known POC all corroborate low real-world exploitation likelihood. The genuine impact is reliability and potential kernel memory corruption on the narrow subset of systems that combine NVMe multipath with sparse NUMA node IDs (primarily certain powerpc/POWER9 machines); on typical x86 servers with dense node IDs the out-of-bounds access does not occur at all. Net: this is a correctness/robustness fix that operators of affected POWER hardware should patch during normal maintenance, not an emergency for the broad fleet - the high CVSS overstates urgency for the vast majority of Linux deployments.
Exploit ScenarioDerived

On a POWER9 host whose firmware reports sparse NUMA node IDs (e.g. 0, 8, 252-255), the kernel attaches an NVMe namespace and calls nvme_mpath_revalidate_paths, which writes head->current_path[numa_node_id()] using a node ID far larger than the six allocated slots, corrupting the adjacent slab object and tripping KASAN. No attacker action or input is required - the condition is reached by normal device probing - so the realistic outcome is memory corruption / crash rather than a controllable remote exploit; no POC is known.
Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Aug 17, 2026

Out-of-bounds slab write in the Linux kernel's NVMe-multipath driver (nvme_mpath_revalidate_paths) affects hosts whose NUMA node IDs are sparse rather than densely packed from zero, notably some powerpc/POWER9 systems. The nvme_ns_head.current_path[] flexible array is sized with num_possible_nodes() but indexed with the raw numa_node_id(), so on non-contiguous topologies the driver writes a pointer past the end of the allocation during namespace scanning, producing the KASAN slab-out-of-bounds splat shown in the report. No public exploit identified at time of analysis; EPSS is low (0.18%, 7th percentile) and it is not on CISA KEV, despite an inflated NVD score of 9.8.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, or 7.1.5 (mainline 7.2-rc1) - whichever matches your branch; the fix simply sizes current_path[] with nr_node_ids instead of num_possible_nodes(). The corresponding commits are at https://git.kernel.org/stable/c/7e7b167e65610dfa7564d449474f4b477f9d4c1c and the other git.kernel.org references in the feed. There is no clean runtime workaround because the allocation happens automatically when NVMe namespaces are scanned; the only practical compensating controls are to prioritize patching affected powerpc/POWER9 hosts (or any platform reporting sparse NUMA node IDs) and, where patching must wait, to avoid deploying NVMe multipath on such systems - a trade-off that removes path redundancy and node-local I/O optimization. Systems with dense, contiguous NUMA node IDs are not exposed and can patch on their normal cycle.

Affected VersionsENISA

Linux patch: 0
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <1d4131b5c9823c7d2c86389898ad1b466af7df5e
Linux patch: 6.6.145
Linux patch: 6.18.40
Linux patch: 6.12.97
Linux patch: 5.15.212
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <7e7b167e65610dfa7564d449474f4b477f9d4c1c
Linux patch: 7.2-rc1
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <316b5f1168264844aa125959de1d6da2b1905795
Linux patch: 5.10.261
Linux patch: 7.1.5
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <7173a741fed73de6247384056fe92e582ba12507
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <bde4d6eb53f7d3cdae7e62c9ee84345fdd6e70a6
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <001e57554de81aa79c25c18fd53911d8a415c304
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <140d6fff4ed266592492a23444043842b4af7a62
Linux patch: 6.1.178
Linux f333444708f82c4a4d3ccac004da0bfd9cfdfa42 <9ffdd11bd6c961b46b3689850ff6c5d7af5c5fe5
Linux 4.20

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Sign in to check
Technical ContextAI · show details

struct nvme_ns_head ends in a flexible array member current_path[], which the NVMe multipath layer uses to cache the preferred I/O path per NUMA node so that head->current_path[numa_node_id()] returns a node-local path. The structure is allocated with kzalloc of sizeof(struct nvme_ns_head) + num_possible_nodes() * sizeof(struct nvme_ns *). num_possible_nodes() returns the count of possible nodes, which only equals the largest node ID + 1 when node IDs are dense (0..N-1). nr_node_ids, by contrast, reflects the maximum possible node ID and is the correct dimension for an array indexed by numa_node_id(). On architectures like powerpc where the firmware can expose sparse node IDs (e.g. 0, 8, 252, 253, 254, 255 giving num_possible_nodes()=6 but node IDs up to 255), indexing by the real node ID reaches far beyond the six allocated slots. The root cause is a classic out-of-bounds write (CWE-787) driven by a size/index mismatch on a flex-array member; the CWE field is N/A in the feed but the 'Buffer Overflow' tag matches. The fix changes the allocation to use nr_node_ids.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources
Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY 9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 4.7 MEDIUM

Triggered locally by kernel NVMe scanning only on sparse-NUMA hardware (AV:L, AC:H) and requires privileged control over hardware/kernel config (PR:H); impact is kernel memory corruption/crash, so A:H, I:L, C:N.

3.1 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H
4.0 AV:L/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat 5.5 MEDIUM

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Aug 17, 2026 - 06:22 NVD
9.8 (CRITICAL)
Patch available
Aug 15, 2026 - 07:19 EUVD
CVE Published
Aug 15, 2026 - 05:59 cve.org
CRITICAL 9.8
CVE Published
Aug 15, 2026 - 05:59 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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 ViewAI

Why It Matters

CVE-2026-74384 is a critical out-of-bounds memory write in the Linux kernel's NVMe-multipath driver affecting hosts with non-contiguous NUMA node topologies, particularly POWER9 systems. While technically critical, real-world exploitation risk is low: no public exploit identified at time of analysis, not listed on CISA KEV, and EPSS is 0.2% (7th percentile). Organizations operating affected infrastructure should prioritize patching to prevent potential kernel memory corruption and service disruption.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 93% exploitable
Prevalence
Ubiquitous
Linux kernel runs nearly everywhere; vulnerable NVMe-multipath sparse-NUMA path is narrow
Data Quality
5 sources
Confidence: Medium
EUVD NVD CVE.org EPSS Vendor

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

49
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +49
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Buffer Overflow HIGH

A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.

Same technique Buffer Overflow

View all
CVE-2017-7269 CRITICAL POC
9.8
CVE-2015-5119 CRITICAL POC
9.8
CVE-2015-3113 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2020-0796 CRITICAL POC
10.0
CVE-2019-11043 CRITICAL POC
9.8
CVE-2009-0927 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-74384 ADVISORY https://ubuntu.com/security/notices/USN-8781-1 REF https://git.kernel.org/stable/c/001e57554de81aa79c25c18fd53911d8a415c304 REF https://git.kernel.org/stable/c/140d6fff4ed266592492a23444043842b4af7a62 REF https://git.kernel.org/stable/c/1d4131b5c9823c7d2c86389898ad1b466af7df5e REF https://git.kernel.org/stable/c/316b5f1168264844aa125959de1d6da2b1905795 REF https://git.kernel.org/stable/c/7173a741fed73de6247384056fe92e582ba12507 REF https://git.kernel.org/stable/c/7e7b167e65610dfa7564d449474f4b477f9d4c1c REF https://git.kernel.org/stable/c/9ffdd11bd6c961b46b3689850ff6c5d7af5c5fe5 REF https://git.kernel.org/stable/c/bde4d6eb53f7d3cdae7e62c9ee84345fdd6e70a6

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy