CVE-2024-43914 in Linux
Summary
by MITRE • 08/26/2024
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: 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
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2024
The vulnerability described in CVE-2024-43914 affects the Linux kernel's mdraid subsystem, specifically within the raid5 implementation. This issue manifests as a kernel panic during the reshape operation of RAID arrays when attempting to revert a reshape operation while reassembling a degraded array. The problem occurs in the md/raid5.c file at line 6278, where a BUG_ON() macro triggers a kernel oops condition that halts system operation. The vulnerability is particularly concerning as it represents a denial of service condition that can occur during routine array management operations.
The technical root cause involves a mismatch between the raid_disks count and the reshape position tracking within the metadata. When mdadm executes the --revert-reshape command, it updates the raid_disks value from 5 to 4, but the reshape position information remains in the superblock metadata. During the reassembly process, the system reads the reshape position from the superblock and attempts to validate it against the new disk count. This validation fails because the writepos calculation uses the old reshape position values, leading to an invalid state that triggers the BUG_ON() macro. The call trace shows the execution path through reshape_request, raid5_sync_request, md_do_sync, and md_thread functions, demonstrating the cascade of operations that leads to the kernel panic.
This vulnerability impacts the operational stability of Linux systems using mdraid arrays, particularly those undergoing reshape operations or recovery scenarios. The panic occurs during what should be a routine administrative operation, making it especially problematic for production environments where system availability is critical. The issue affects systems running kernel versions that include the problematic md/raid5 implementation, and represents a failure in the metadata consistency validation mechanisms. From an ATT&CK perspective, this vulnerability could be leveraged in a denial of service attack against systems relying on mdraid storage, potentially affecting system availability and data access. The CWE classification would be CWE-248, as it involves an improper control flow management where an unexpected condition causes an abnormal program termination.
The fix implemented converts the BUG_ON() macro to WARN_ON() and adds proper error handling to stop the reshape operation when validation checks fail, rather than allowing the kernel to panic. This approach prevents system crashes while still alerting administrators to the problematic state. However, the fundamental issue remains that the metadata consistency is not properly validated during reassembly operations. The suggested mitigation involves both kernel-level fixes to improve metadata validation and mdadm-level improvements to properly handle the --revert-reshape functionality. This dual approach addresses both the immediate panic condition and the underlying metadata inconsistency that causes the problem. Organizations should ensure their systems are updated with kernel versions containing this fix, and should also verify that their mdadm tools are current to prevent triggering this condition during normal array management operations.