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.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*

History

17 Mar 2025, 16:56

Type Values Removed Values Added
CPE cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*
First Time Linux
Linux linux Kernel
References () https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417 - () https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417 - Patch
References () https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe - () https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe - Patch
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
CWE CWE-459

21 Nov 2024, 09:03

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417 - () https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417 -
References () https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe - () https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe -
Summary
  • (es) 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-&gt;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 [&lt;0&gt;] stop_sync_thread+0x1ab/0x270 [md_mod] [&lt;0&gt;] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [&lt;0&gt;] raid_presuspend+0x1e/0x70 [dm_raid] [&lt;0&gt;] dm_table_presuspend_targets+0x40/0xb0 [ dm_mod] [&lt;0&gt;] __dm_destroy+0x2a5/0x310 [dm_mod] [&lt;0&gt;] dm_destroy+0x16/0x30 [dm_mod] [&lt;0&gt;] dev_remove+0x165/0x290 [dm_mod] [&lt;0&gt;] ctl_ioctl+0x4bb/ 0x7b0 [dm_mod] [&lt;0&gt;] dm_ctl_ioctl+0x11/0x20 [dm_mod] [&lt;0&gt;] vfs_ioctl+0x21/0x60 [&lt;0&gt;] __x64_sys_ioctl+0xb9/0xe0 [&lt;0&gt;] do_syscall_64+0xc6/0x230 [&lt;0 &gt;] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Mientras tanto mddev-&gt;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.

03 Apr 2024, 17:24

Type Values Removed Values Added
New CVE

Information

Published : 2024-04-03 17:15

Updated : 2025-03-17 16:56


NVD link : CVE-2024-26756

Mitre link : CVE-2024-26756

CVE.ORG link : CVE-2024-26756


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-459

Incomplete Cleanup