CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26763 – dm-crypt: don't modify the data when using authenticated encryption
https://notcve.org/view.php?id=CVE-2024-26763
In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dm-crypt: no modifica los datos cuando se utiliza cifrado autenticado Se dijo que el cifrado autenticado podría producir etiquetas no válidas cuando se modifican los datos que se están cifrando [1]. Entonces, solucione este problema copiando primero los datos en la biografía del clon y luego cifrándolos dentro de la biografía del clon. Esto puede reducir el rendimiento, pero es necesario para evitar que el usuario dañe el dispositivo escribiendo datos con O_DIRECT y modificándolos al mismo tiempo. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ • https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90 https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529 https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6 https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75 https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857 https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b8047828 •
CVSS: -EPSS: 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 •
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: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26744 – RDMA/srpt: Support specifying the srpt_service_guid parameter
https://notcve.org/view.php?id=CVE-2024-26744
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srpt: admite la especificación del parámetro srpt_service_guid. Hace que la carga de ib_srpt con este conjunto de parámetros funcione. El comportamiento actual es que configurar ese parámetro mientras se carga el módulo del kernel ib_srpt desencadena el siguiente fallo del kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 Seguimiento de llamadas: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/ 0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 A flaw was foundin the Linux Kernel when specifying the srpt_service_guid parameter, which may lead to kernel crash. • https://git.kernel.org/stable/c/a42d985bd5b234da8b61347a78dc3057bf7bb94d https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82 https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4 https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8 https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f3375778 • CWE-476: NULL Pointer Dereference •