| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-26757: md: Don't ignore read-only array in md_check_recovery() |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| md: Don't ignore read-only array in md_check_recovery() |
| |
| Usually if the array is not read-write, md_check_recovery() won't |
| register new sync_thread in the first place. And if the array is |
| read-write and sync_thread is registered, md_set_readonly() will |
| unregister sync_thread before setting the array read-only. md/raid |
| follow this behavior hence there is no problem. |
| |
| After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following |
| hang can be triggered by test shell/integrity-caching.sh: |
| |
| 1) array is read-only. dm-raid update super block: |
| rs_update_sbs |
| ro = mddev->ro |
| mddev->ro = 0 |
| -> set array read-write |
| md_update_sb |
| |
| 2) register new sync thread concurrently. |
| |
| 3) dm-raid set array back to read-only: |
| rs_update_sbs |
| mddev->ro = ro |
| |
| 4) stop the array: |
| raid_dtr |
| md_stop |
| stop_sync_thread |
| set_bit(MD_RECOVERY_INTR, &mddev->recovery); |
| md_wakeup_thread_directly(mddev->sync_thread); |
| wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) |
| |
| 5) sync thread done: |
| md_do_sync |
| set_bit(MD_RECOVERY_DONE, &mddev->recovery); |
| md_wakeup_thread(mddev->thread); |
| |
| 6) daemon thread can't unregister sync thread: |
| md_check_recovery |
| if (!md_is_rdwr(mddev) && |
| !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) |
| return; |
| -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; |
| |
| The root cause is that dm-raid manipulate 'mddev->ro' by itself, |
| however, dm-raid really should stop sync thread before setting the |
| array read-only. Unfortunately, I need to read more code before I |
| can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix |
| the problem the easy way for now to prevent dm-raid regression. |
| |
| The Linux kernel CVE team has assigned CVE-2024-26757 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 4.8 with commit ecbfb9f118bce49f571675929160e4ecef91cc8a and fixed in 6.7.7 with commit 2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 |
| Issue introduced in 4.8 with commit ecbfb9f118bce49f571675929160e4ecef91cc8a and fixed in 6.8 with commit 55a48ad2db64737f7ffc0407634218cc6e4c513b |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2024-26757 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/md/md.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 |
| https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b |