Skip to main content

Linux Kernel EUVDEUVD-2026-59337

| CVE-2026-72438 HIGH
2026-08-15 Linux GHSA-cxhw-2fw5-695j
Information Disclosure Linux Red Hat Suse
7.5
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Block device discard operations are kernel-space events requiring local access and at least low-privileged block device reach, making AV:L and PR:L more accurate than the provided AV:N/PR:N.

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

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Aug 17, 2026 - 09:25 vuln.today
CVSS changed
Aug 17, 2026 - 06:22 NVD
7.5 (HIGH)
Patch available
Aug 15, 2026 - 07:20 EUVD
CVE Published
Aug 15, 2026 - 05:56 cve.org
HIGH 7.5
CVE Published
Aug 15, 2026 - 05:56 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

md/raid10: fix writes_pending and barrier reference leaks on discard failures

raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped.

Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced.

Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference.

Release the barrier before returning from those paths.

AnalysisAI

Reference accounting defects in the Linux kernel's md/raid10 driver allow writes_pending and barrier references to permanently leak on discard operation failure paths, leading to an unrecoverable hang of the RAID10 array. raid10_make_request() acquires these references before entering raid10_handle_discard(), but multiple failure exits in that function bypass the corresponding release calls md_write_end() and allow_barrier(), causing write accounting and resync barriers to become permanently imbalanced. With no confirmed active exploitation (no CISA KEV listing), an EPSS of 0.16% at the 6th percentile, and no public exploit identified at time of analysis, this is a targeted kernel-configuration issue whose impact is confined to systems explicitly running md/raid10 with discard enabled.

Technical ContextAI

The Linux kernel's md (multiple-device) subsystem implements software RAID, with the raid10 driver providing RAID 10 - a combination of mirroring and striping for fault tolerance and I/O performance. Discard operations (TRIM/UNMAP) notify underlying storage that certain blocks are no longer in use, critical for SSD wear leveling and thin-provisioned backends. The raid10_make_request() function is the central I/O entry point: it calls md_write_start() to increment the writes_pending atomic counter and wait_barrier() to acquire a resync barrier before delegating discard I/O to raid10_handle_discard(). The defect is a resource reference counting error - several error-handling branches inside raid10_handle_discard() complete the bio and return without pairing these acquisitions with their corresponding md_write_end() and allow_barrier() release calls. Repeated trigger events cause the pending-write counter to accumulate without decrement, eventually stalling array shutdown or resync operations indefinitely. The CWE is listed as N/A by the reporter, but the root cause is consistent with CWE-772 (Missing Release of Resource after Effective Lifetime). The CPE cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* confirms broad applicability across Linux kernel versions and architectures where md/raid10 is compiled in.

RemediationAI

Apply one of the upstream fix commits from the Linux kernel stable tree: commit 393d687131d8aa8c7e4de2cb494438e145d20fc2 or d1324b41dabd26787559efaeb430643c627c1eb0, available respectively at https://git.kernel.org/stable/c/393d687131d8aa8c7e4de2cb494438e145d20fc2 and https://git.kernel.org/stable/c/d1324b41dabd26787559efaeb430643c627c1eb0. For packaged distributions, upgrade to Linux 5.15.111 or later in the 5.15.x stable series, or Linux 7.1.5 or later in the main line. If immediate patching is not feasible, a targeted workaround is to disable discard pass-through on md/raid10 arrays by omitting the discard flag from the array configuration or by setting 'discard_supported=0' where applicable - this prevents the vulnerable raid10_handle_discard() code path from being entered entirely, at the cost of reduced SSD performance and increased storage fragmentation on thin-provisioned backends. Restarting md arrays that may already have accumulated reference leaks (detectable as arrays that hang on stop or resync) requires a full system reboot to reset the atomic counters.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 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

Share

EUVD-2026-59337 vulnerability details – vuln.today
Back

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