CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26759 – mm/swap: fix race when skipping swapcache
https://notcve.org/view.php?id=CVE-2024-26759
In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() with same entry <direct swapin path> <direct swapin path> <alloc page A> <alloc page B> swap_read_folio() <- read to page A swap_read_folio() <- read to page B <slow on later locks or interrupt> <finished swapin first> ... set_pte_at() swap_free() <- entry is free <write to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! • https://git.kernel.org/stable/c/0bcac06f27d7528591c27ac2b093ccd71c5d0168 https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95 https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458 https://access.redhat.com/security/cve/CVE-2024-26759 https://bugzilla.redhat.com/show_bug.cgi?id=2273204 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26758 – md: Don't ignore suspended array in md_check_recovery()
https://notcve.org/view.php?id=CVE-2024-26758
In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes 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)) 3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) daemon thread can't unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No ignorar la matriz suspendida en md_check_recovery() mddev_suspend() nunca detiene sync_thread, por lo tanto, no tiene sentido ignorar la matriz suspendida en md_check_recovery(), lo que podría causar sync_thread no se puede cancelar el registro. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo se puede activar mediante test shell/integrity-caching.sh: 1) suspender la matriz: raid_postsuspend mddev_suspend 2) detener la matriz: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR , &mddev->recuperación); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., ! • https://git.kernel.org/stable/c/68866e425be2ef2664aa5c691bb3ab789736acf5 https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0 https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757 https://access.redhat.com/security/cve/CVE-2024-26758 https://bugzilla.redhat.com/show_bug.cgi?id=2273206 • CWE-20: Improper Input Validation CWE-129: Improper Validation of Array Index •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26757 – md: Don't ignore read-only array in md_check_recovery()
https://notcve.org/view.php?id=CVE-2024-26757
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. • https://git.kernel.org/stable/c/ecbfb9f118bce49f571675929160e4ecef91cc8a https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b https://access.redhat.com/security/cve/CVE-2024-26757 https://bugzilla.redhat.com/show_bug.cgi?id=2273208 • CWE-20: Improper Input Validation CWE-404: Improper Resource Shutdown or Release •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26756 – md: Don't register sync_thread for reshape directly
https://notcve.org/view.php?id=CVE-2024-26756
In the Linux kernel, the following vulnerability has been resolved: md: Don't register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No registre sync_thread para remodelar directamente Actualmente, si se interrumpe el proceso de remodelación, volver a ensamblar la matriz registrará sync_thread directamente desde pers->run(), en este caso 'MD_RECOVERY_RUNNING ' se configura directamente, sin embargo, no hay garantía de que md_do_sync() se ejecute, por lo tanto, stop_sync_thread() se bloqueará porque 'MD_RECOVERY_RUNNING' no se puede borrar. En el último parche, asegúrese de que md_do_sync() establezca MD_RECOVERY_DONE; sin embargo, dm-raid test shell/lvconvert-raid-reshape.sh ocasionalmente puede activar el siguiente bloqueo: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [ dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/ 0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0 >] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Mientras tanto mddev->recovery es: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Solucione este problema eliminando el código para registrar sync_thread directamente desde raid10 y raid5. Y deje que md_check_recovery() registre sync_thread. • https://git.kernel.org/stable/c/f67055780caac6a99f43834795c43acf99eba6a6 https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417 https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe •
CVSS: 5.3EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26755 – md: Don't suspend the array for interrupted reshape
https://notcve.org/view.php?id=CVE-2024-26755
In the Linux kernel, the following vulnerability has been resolved: md: Don't suspend the array for interrupted reshape md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won't happen at all or data will be corrupted(remove_and_add_spares won't be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won't start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe because conf won't be changed until reshape is done. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No suspender la matriz por remodelación interrumpida md_start_sync() suspenderá la matriz si hay repuestos que se pueden agregar o eliminar de conf, sin embargo, si la remodelación aún está en marcha progreso, esto no sucederá en absoluto o los datos se dañarán (no se llamará a remove_and_add_spares desde md_choose_sync_action para remodelar), por lo tanto, no hay necesidad de suspender la matriz si la remodelación aún no se ha realizado. Mientras tanto, existe un posible punto muerto para raid456: 1) se interrumpe la remodelación; 2) configure uno de los discos WantReplacement y agregue un nuevo disco a la matriz; sin embargo, la recuperación no comenzará hasta que finalice la remodelación; 3) luego emita una IO a través de la posición de reshpae, esta IO esperará a que la remodelación avance; 4) continúe remodelando, luego md_start_sync() encontró que hay un disco de repuesto que se puede agregar a conf, se llama a mddev_suspend(); Los pasos 4 y 3 se esperan el uno al otro y se activa el punto muerto. Observé que este problema se encuentra mediante la revisión del código y aún no se ha informado. • https://git.kernel.org/stable/c/bc08041b32abe6c9824f78735bac22018eabfc06 https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48 https://git.kernel.org/stable/c/9e46c70e829bddc24e04f963471e9983a11598b7 •