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 BUGON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUGON() 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: md0reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshaperequest+0x3f1/0xe60 Call Trace: <TASK> raid5syncrequest+0x43d/0x550 mddosync+0xb7a/0x2110 mdthread+0x294/0x2b0 kthread+0x147/0x1c0 retfromfork+0x59/0x70 retfromforkasm+0x1a/0x30 </TASK>
Root cause is that --revert-reshape update the raiddisks 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 BUGON() to WARNON(), 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.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUGON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUGON() 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: md0reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshaperequest+0x3f1/0xe60 Call Trace: <TASK> raid5syncrequest+0x43d/0x550 mddosync+0xb7a/0x2110 mdthread+0x294/0x2b0 kthread+0x147/0x1c0 retfromfork+0x59/0x70 retfromforkasm+0x1a/0x30 </TASK>
Root cause is that --revert-reshape update the raiddisks 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 BUGON() to WARNON(), 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.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.27-1 - Upgrade
Upgrade
debian/linux-6.1to a version that resolves this vulnerability.Fixed in 6.1.129-1~deb11u1
Event History
Frequently Asked Questions
What is the severity of CVE-2024-43914?
CVE-2024-43914 is classified with a medium severity level due to its impact on system stability during RAID array reshaping.
How do I fix CVE-2024-43914?
To fix CVE-2024-43914, upgrade the Linux kernel to the recommended versions listed in the vulnerability report.
Which Linux kernel versions are affected by CVE-2024-43914?
CVE-2024-43914 affects several Linux kernel versions including those prior to 5.10.226-1 and various 6.x versions up to 6.12.11-1.
What kind of systems are impacted by CVE-2024-43914?
CVE-2024-43914 impacts Linux systems using the md/raid5 module for RAID array management.
Is CVE-2024-43914 a remote vulnerability?
No, CVE-2024-43914 is not a remote vulnerability; it involves local operations during array reshaping.