CVE-2024-43914: md/raid5: avoid BUG_ON() while continue reshape after reassembling
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUG_ON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
<TASK>
raid5_sync_request+0x43d/0x550
md_do_sync+0xb7a/0x2110
md_thread+0x294/0x2b0
kthread+0x147/0x1c0
ret_from_fork+0x59/0x70
ret_from_fork_asm+0x1a/0x30
</TASK>
Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.
Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.
Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel RAID5 reliability flaw. Under a specific mdadm revert-reshape/reassembly condition, the kernel can hit a BUG_ON and panic instead of safely stopping the bad reshape. The practical concern is service downtime or data-recovery disruption on hosts using Linux software RAID reshape operations, not a broadly documented remote attack.
Executive priority
Treat this as a targeted availability risk for Linux software RAID environments. It is most urgent for storage-heavy systems, recovery workflows, and hosts where RAID reshape is planned or recently failed. Patch through normal kernel maintenance unless those conditions exist, then accelerate.
Technical view
In md/raid5, mdadm --revert-reshape can change raid_disks while a reshape position remains in metadata. After reassembly, the kernel reads the old reshape position, calculates writepos incorrectly, fails consistency checks, and previously triggered BUG_ON. The kernel fix converts the BUG_ON to WARN_ON and stops reshape when checks fail.
Likely exposure
Exposure appears limited to Linux systems using md/raid5 software RAID, especially where reshape, revert-reshape, or reassembly operations occur. The source bundle lists affected Linux kernel versions and stable fixes, but does not identify exposed network services or remotely reachable attack surfaces.
Exploitation context
No active exploitation is supported by the supplied sources, and the CVE is not marked KEV. The described trigger comes from mdadm reshape/reassembly behavior and a test case. Evidence supports an availability failure path, not public weaponization or remote exploitation.
Researcher notes
The key failure is unsafe handling of inconsistent reshape metadata after mdadm --revert-reshape. Sources explicitly say the kernel fix is an initial defensive change and that mdadm plus metadata validation may still need improvement. No CVSS, CWE, or exploit proof is provided.
Mitigation direction
Apply vendor kernel updates containing the referenced stable md/raid5 fixes.
Review Debian LTS advisories if running affected Debian kernel packages.
Avoid unnecessary RAID5 reshape or revert-reshape operations until patched.
Check mdadm/vendor guidance because the source notes mdadm also needs correction.
Prioritize backups before storage reshape or recovery work.
Validation and detection
Inventory Linux hosts using md/raid5 software RAID arrays.
Confirm running kernel versions against affected and fixed vendor package versions.
Check package advisories for Debian or other distributions in use.
Review logs for md/raid5 reshape warnings, BUG_ON panics, or failed reassembly events.
Validate mdadm version and vendor notes for revert-reshape behavior.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-43914 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.