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: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26754 – gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
https://notcve.org/view.php?id=CVE-2024-26754
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? • https://git.kernel.org/stable/c/459aa660eb1d8ce67080da1983bb81d716aa5a69 https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861 https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7 https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77 https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-26752 – l2tp: pass correct message length to ip6_append_data
https://notcve.org/view.php?id=CVE-2024-26752
In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: l2tp: pasa la longitud correcta del mensaje a ip6_append_data l2tp_ip6_sendmsg necesita evitar tener en cuenta el encabezado de transporte dos veces al unir más datos en un skbuff ya parcialmente ocupado. Para gestionar esto, verificamos si skbuff contiene datos usando skb_queue_empty al decidir cuántos datos agregar usando ip6_append_data. Sin embargo, el código que realizó el cálculo era incorrecto: ulen = len + skb_queue_empty(&sk->sk_write_queue)? • https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59 https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6 https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070 https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844 https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0 •