CVE-2026-45953: Linux Kernel RAID5 DoS Vulnerability

CVE-2026-45953 Overview

CVE-2026-45953 is a Linux kernel vulnerability in the md/raid5 subsystem. The flaw causes an IO hang on a degraded RAID5 array when llbitmap is in use. When an llbitmap bit state remains unwritten, the kernel fails to consistently force a read-construct-write (RCW) path during stripe handling. This inconsistency causes the stripe handler to enter a deadloop, blocking IO progress on affected arrays.

The issue stems from a missing check in need_this_block() that is correctly present in handle_stripe_dirtying(). The vulnerability has been resolved in the upstream kernel through three commits referenced in git.kernel.org.

Critical Impact
Affected systems running degraded RAID5 arrays with llbitmap can experience stalled IO and storage unavailability, leading to denial of service conditions on storage workloads.

Affected Products

Linux kernel versions implementing md/raid5 with llbitmap support
Storage systems using software RAID5 in degraded state
Distributions shipping the affected kernel commits prior to the fix

Discovery Timeline

2026-05-27 - CVE-2026-45953 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45953

Vulnerability Analysis

The vulnerability resides in the Linux kernel md/raid5 driver path responsible for handling stripe operations when the array operates in a degraded state with the low-latency bitmap (llbitmap) feature enabled. The bitmap_ops->blocks_synced() callback indicates whether a bitmap bit state has been written to persistent storage. When the bit state is still unwritten, the kernel must force RCW for any new write to maintain data consistency.

handle_stripe_dirtying() correctly consults blocks_synced() to decide whether to force RCW. However, need_this_block() does not perform the same check. When handle_stripe() falls through to handle_stripe_fill() and queries need_this_block(), the function always returns 0, so no block is scheduled for IO. The stripe remains in an unresolved state and handle_stripe() loops without making progress, producing an observable IO hang.

This is a logic flaw in the kernel rather than a memory-safety issue. The impact is loss of availability for storage workloads using the affected configuration.

Root Cause

The root cause is an inconsistent state check across two functions that participate in stripe handling. handle_stripe_dirtying() accounts for unwritten llbitmap bit state, while need_this_block() does not. Stripe handling decisions diverge when the bitmap state is still pending, leaving the stripe in a path where no block is selected for IO and the handler cannot complete.

Attack Vector

The vulnerability is triggered by normal write activity to a degraded RAID5 array configured with llbitmap. No authentication bypass or remote vector is documented. Triggering requires a degraded array, pending llbitmap bit state, and incoming writes that route through the affected stripe handling code path. The result is an IO hang and denial of service for the affected storage volume.

No verified exploit code is available. The fix is delivered as three upstream kernel commits: 28ef299e7a5b, 870b9f15867b, and cd1635d844d2. See the Kernel Git Commit Details for the corrective patch.

Detection Methods for CVE-2026-45953

Indicators of Compromise

Stalled or hung tasks reported in dmesg referencing md_raid5 or raid5d kernel threads
IO requests stuck in D state on block devices backed by a degraded RAID5 array with llbitmap
Application-level write timeouts on filesystems mounted over affected MD devices

Detection Strategies

Inventory hosts running Linux kernels that include llbitmap support and software RAID5 arrays
Correlate /proc/mdstat output showing degraded arrays with kernel version data to identify exposure
Monitor kernel logs for hung_task warnings and stack traces involving handle_stripe, handle_stripe_dirtying, or need_this_block

Monitoring Recommendations

Collect kernel logs and block device IO latency metrics into a centralized SIEM for trend analysis
Alert on sustained zero-throughput conditions on MD RAID5 devices
Track array state transitions to identify when arrays enter a degraded condition

How to Mitigate CVE-2026-45953

Immediate Actions Required

Identify systems running affected kernels with software RAID5 arrays using llbitmap
Schedule kernel updates to a build containing commits 28ef299e7a5b, 870b9f15867b, or cd1635d844d2
Restore degraded arrays to a fully synchronized state to reduce the window in which the bug can manifest

Patch Information

The fix has been merged upstream. Apply the kernel update referenced by the three commits on git.kernel.org: commit 28ef299e7a5b, commit 870b9f15867b, and commit cd1635d844d2. Rebuild and reboot into the patched kernel after applying distribution updates.

Workarounds

Avoid running RAID5 arrays in a degraded state for extended periods; replace failed members promptly
Where feasible, disable llbitmap and use the legacy bitmap implementation until the patched kernel is deployed
Reduce write pressure on degraded arrays to minimize the chance of triggering the hung stripe path

bash

# Verify kernel version and inspect MD array state
uname -r
cat /proc/mdstat

# Check for hung tasks related to raid5 stripe handling
dmesg -T | grep -E 'hung_task|raid5|handle_stripe'