Skip to main content

Linux Kernel EUVDEUVD-2026-32237

| CVE-2026-45953 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-w54p-gjcx-42f6
Linux Information Disclosure Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

AC:H reflects that exploitation requires a degraded RAID5 array with llbitmap in unwritten state - conditions outside attacker control; C:N/I:N confirmed by description and CVSS.

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

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 16, 2026 - 02:39 vuln.today
CVSS changed
Jun 16, 2026 - 02:37 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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

md/raid5: fix IO hang with degraded array with llbitmap

When llbitmap bit state is still unwritten, any new write should force rcw, as bitmap_ops->blocks_synced() is checked in handle_stripe_dirtying(). However, later the same check is missing in need_this_block(), causing stripe to deadloop during handling because handle_stripe() will decide to go to handle_stripe_fill(), meanwhile need_this_block() always return 0 and nothing is handled.

AnalysisAI

IO deadloop in Linux kernel's md/raid5 subsystem causes complete availability loss on systems running degraded RAID5 arrays with llbitmap enabled. When llbitmap bit state is 'unwritten', the missing synchronization check in need_this_block() diverges from the check present in handle_stripe_dirtying(), trapping handle_stripe() in an infinite loop that never makes progress - effectively hanging all IO on the affected array. No public exploit is identified at time of analysis, and EPSS at 0.02% (4th percentile) reflects very low real-world exploitation probability, consistent with the narrow deployment conditions required.

Technical ContextAI

The Linux kernel's md (Multiple Devices) subsystem implements software RAID, including RAID5 with parity. The 'llbitmap' (lazy logging bitmap) tracks which RAID stripes are dirty; when a stripe's bit state is marked 'unwritten', the kernel should force a RCW (Read-Compute-Write) cycle to ensure data consistency. The bug is a logic inconsistency: handle_stripe_dirtying() correctly consults bitmap_ops->blocks_synced() to determine whether RCW is needed, but need_this_block() - called later in the same stripe handling path - omits the same check. This causes handle_stripe() to repeatedly dispatch to handle_stripe_fill() expecting blocks to be fetched, while need_this_block() always returns 0 signalling nothing is needed, resulting in a deadloop. The CWE is not formally assigned, but the root cause class is a missing synchronization/consistency check (analogous to CWE-362 or CWE-670, logic conditions handled inconsistently across a code path). Affected CPE: cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel release: 6.18.14 or later for the 6.18 stable series, 6.19.4 or later for the 6.19 series, or mainline 7.0+. Upstream fix commits are available at https://git.kernel.org/stable/c/28ef299e7a5b81817f8ca8297c2ddff28f5da5e8, https://git.kernel.org/stable/c/870b9f15867b0e70f3459ef3974b043e8b229690, and https://git.kernel.org/stable/c/cd1635d844d26471c56c0a432abdee12fc9ad735. For systems that cannot be patched immediately, a targeted compensating control is to disable llbitmap on RAID5 arrays: use 'mdadm --bitmap=none /dev/mdX' to remove the bitmap, or avoid the bitmap=internal option when assembling arrays - this prevents the unwritten-bit state from ever being reached, eliminating the vulnerable code path. The trade-off is loss of lazy bitmap tracking, which may increase resync time after unclean shutdowns. Alternatively, keeping degraded RAID5 arrays offline or in read-only mode until rebuilt eliminates the write path that triggers the deadloop, at the cost of reduced availability during disk replacement. Vendor advisory: https://nvd.nist.gov/vuln/detail/CVE-2026-45953.

Same technique Information Disclosure

View all
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
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected

Share

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

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