PatchSiren cyber security CVE debrief
CVE-2026-45953 Linux CVE debrief
A logic error in the Linux kernel's RAID5 implementation can cause I/O operations to hang indefinitely when using a degraded array with the lazy-latency bitmap (llbitmap) feature. The vulnerability stems from a missing consistency check in the `need_this_block()` function that creates a deadlock condition during stripe handling. When the llbitmap bit state remains unwritten and new write operations force a reconstruct-write (rcw) cycle, the stripe handling code enters `handle_stripe_fill()` but `need_this_block()` consistently returns zero, preventing any forward progress. This results in a deadloop where no I/O is processed. The issue affects systems running software RAID5 with bitmap-based write-intent logging in degraded configurations. Kernel patches have been committed to stable branches to add the missing `bitmap_ops->blocks_synced()` check in `need_this_block()`, ensuring proper synchronization state validation before stripe processing decisions.
- Vendor
- Linux
- Product
- Unknown
- CVSS
- Unknown
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-05-27
- Original CVE updated
- 2026-05-27
- Advisory published
- 2026-05-27
- Advisory updated
- 2026-05-27
Who should care
System administrators managing Linux software RAID5 arrays, particularly those using write-intent bitmaps for resync acceleration. Organizations running storage servers or virtualized infrastructure on kernel-based RAID configurations. Kernel maintainers and Linux distribution security teams responsible for stable kernel updates.
Technical summary
The vulnerability exists in the md/raid5 driver when handling stripes on degraded arrays using the lazy-latency bitmap (llbitmap) feature. The code path through `handle_stripe_dirtying()` correctly checks `bitmap_ops->blocks_synced()` to force reconstruct-write (rcw) operations when bitmap bits are unwritten. However, `need_this_block()` lacks this check, causing it to return zero in scenarios where stripe filling is required. This creates a livelock: `handle_stripe()` dispatches to `handle_stripe_fill()`, but `need_this_block()` prevents any block processing, resulting in indefinite I/O stalls. The fix adds the missing bitmap synchronization check to `need_this_block()` to maintain consistency with `handle_stripe_dirtying()` logic.
Defensive priority
medium
Recommended defensive actions
- Apply kernel updates from stable branches containing commits 28ef299e7a5b, 870b9f15867b, or cd1635d844d2 as appropriate for your kernel version
- Monitor RAID array health and avoid running RAID5 arrays in degraded state when possible
- Review dmesg logs for md/raid5 stripe handling errors that may indicate this condition
- Consider disabling write-intent bitmaps temporarily on degraded RAID5 arrays if patching is delayed and I/O hangs are observed
- Validate RAID5 array integrity after applying patches and before returning to production workloads
Evidence notes
Vulnerability description sourced from official CVE record published 2026-05-27. Root cause analysis derived from kernel commit messages in stable tree references. Affected component identified as md/raid5 subsystem with llbitmap (lazy-latency bitmap) configuration. Fix commits verified in kernel.org stable repository.
Official resources
-
CVE-2026-45953 CVE record
CVE.org
-
CVE-2026-45953 NVD detail
NVD
-
Source item URL
nvd_modified
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
2026-05-27