CVE-2024-43914

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: avoid BUG_ON() while continue reshape after reassembling<br /> <br /> Currently, mdadm support --revert-reshape to abort the reshape while<br /> reassembling, as the test 07revert-grow. However, following BUG_ON()<br /> can be triggerred by the test:<br /> <br /> kernel BUG at drivers/md/raid5.c:6278!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> irq event stamp: 158985<br /> CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94<br /> RIP: 0010:reshape_request+0x3f1/0xe60<br /> Call Trace:<br /> <br /> raid5_sync_request+0x43d/0x550<br /> md_do_sync+0xb7a/0x2110<br /> md_thread+0x294/0x2b0<br /> kthread+0x147/0x1c0<br /> ret_from_fork+0x59/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Root cause is that --revert-reshape update the raid_disks from 5 to 4,<br /> while reshape position is still set, and after reassembling the array,<br /> reshape position will be read from super block, then during reshape the<br /> checking of &amp;#39;writepos&amp;#39; that is caculated by old reshape position will<br /> fail.<br /> <br /> Fix this panic the easy way first, by converting the BUG_ON() to<br /> WARN_ON(), and stop the reshape if checkings fail.<br /> <br /> Noted that mdadm must fix --revert-shape as well, and probably md/raid<br /> should enhance metadata validation as well, however this means<br /> reassemble will fail and there must be user tools to fix the wrong<br /> metadata.